API password

[itognet]

As everybody knows, it is very easy to find passwords in clear text in many programs.

Could it be a problem if unknown persons reveals my API password forCommitCRM.
I believe that it is possible to extract almost everything from the CommitCRM Database with the API password. Correct ?

Do you have any suggestion on how to handle and protect the API Password.

Thanks.

[Support Team]

As with any API key you should protect it and make sure no one has access to it except you.
Our recommendation is that you generate a password that is hard to guess and long enough, this should protect you pretty well as long as no one external has public access to the place where you store this password in your programs.

HTH

[itognet]

I don't think that you your are getting my point.

API by e-mail is based on the e-mail technology (POP, SMTP and Exchange), which is often very 'open'. (Read: password in clear text, e-mail body in clear text).

Lets take InterLink for example, the e-mails sent from InterLink is always sent in clear text (SMTP). So this way the API passsword is unveiled, for whoever is 'listening' on the line.
It is not difficult to get these data.

About emailed passwords.
Emailed passwords are dangerous for all of the following reasons:
email is sent in plain text
email often is stored on several systems along the way to your mailbox
email often is stored on your computer in plain text or other unencrypted format
many copies may exist in many places, even after "deletion"
even encrypted email can be broken in to, given enough computing time
your account's security may have been compromised even before you read your email (changing the password will not help in this case)

One thing is that your e-mail account can be hacked, but also having e-mails in your account with clear type password!? A password giving you control of data for not only one company but maybe hundreds of companies. Isn't that stupid, when it is possible to encrypt the e-mail before sending, and have CommitCRM to decrypt it.

How should we Commit'eers handle and protect the API password, when it is a no go to have ANY passwords in e-mails. (It would be OK for me, if the e-mail was encrypted).

What are your point of view on this.

Best regards.

[Support Team]

Thank you for the clarification.

Email messages should not necessarily be exposed.

For example, if you run your own mail server and Interlink and RangerMSP runs on your LAN then nothing go out to the Internet. Interlink's email is sent to RangerMSP all within the same LAN so nothing is exposed. At least no emails with passwords.

If your mail server is hosted elsewhere verify that the communication between Interlink to it and between the email connector to it are over SSL. This way the entire traffic to/from the mail server you use is encrypted for you, even for text based emails.
(just verify that both systems connect directly to your external mail server over SSL).

In any case, we're not here to defend email technology or security, and besides anything can get hacked. You have raised some interesting points that we will definitely evaluate. Thank you.

Dina

[lpopejoy]

May I suggest XML/soap over an ssl link? That would be so much better than emailing stuff back and forth. That being said, I can see where that is a big advantage (allowing external systems to send in tickets), but maybe that ability should be limited somehow (perhaps optionally)...

I'm very concerned with security of CommitCRM both on the APi side and the web server side. If any of those were to be exploited, there is a LOT of data there.

One thing I would like to see considered is some encryption possibilities on some fields. (like notes)...

[Support Team]

May I suggest XML/soap over an ssl link? That would be so much better than emailing stuff back and forth.
Well, we are actually working on something like this right now :-)

--
In general we believe that the Web interface is secured and we constantly review it. We are not aware with it even being hacked, however, like everything else on the Web nothing is 100% guaranteed. We do, however, strongly recommend using it with SSL so everything is encrypted all the way from your remote Browser and the server.

Thanks,
Dina

[lpopejoy]

Wow, that's supper cool.

I think I've brought this up before, but I would also like to see ALL access to the web interface logged - ESPECIALLY failed login attempts. I want to be able to audit that log and be alerted if someone is trying to brute force a login... I'm not saying it has to be logged to the database, just a text file would be fine. Is that feasible or am I living in a fantasy world?

[Support Team]

Successful logins are logged. Failed are not logged on purpose. If anyone tries to hack with endless login attempts being logged it might consume a lot of disk space on your server "eating" all its free space, ending up with your server going down... But, in some cases this may indeed by useful. Noted. Thanks.