System -> Password encryption or hashing

[NC Software]

Why are passwords not encrypted or hashed in the database? Passwords should NEVER be human readable, anywhere!

[Jamie Edwards]

In order for clients to receive their ticket password each time they submit a ticket, the passwords cannot be hashed.

The only way for this to happen would be to randomise the password every time they submitted a ticket - which would annoy a lot of them, I'd imagine.

[NC Software]

Passwords should therefore be ENCRYPTED which can be reversed out to clear for your e-mail situation. However, passwords should NEVER be stored in the clear and we have the option whether to include passwords in e-mails. For companies that want full lock down security they won't allow passwords in their e-mail and certainly don't want passwords stored in plain text anywhere, including a database. This is a major security issue that needs to be addressed with highest priority! I came across this when I was resolving my IMAP issue and I did a SELECT * on the database to get all the mail queue's to find the passwords to my e-mail accounts stored in the clear as well. Another major security issue as a sysadmin may be the only one that knows passwords to mailboxes but anyone with access to MySQL and the database can now view them! It's more than just user information, it's a major security issue across the board!

[Jamie Edwards]

Passwords should therefore be ENCRYPTED which can be reversed out to clear for your e-mail situation.

Due to the nature of PHP as a language and platform, this would never be secure - it is unlike C++ (for example) which is obfuscated and then irreversibly (to an extent) compiled. Anyone with a copy of the software could easily decrypt the passwords if they got access to the database.

Of course, we could keep the code that does some form of encryption under the encrypted portion of SupportSuite, but again this is still not extremely secure. If a hacker is determined enough to hack your server, retrieve a copy of your database in order to access the client passwords, the likelihood is that he or she will be determined enough to reverse-engineer the algorithm.

However, passwords should NEVER be stored in the clear and we have the option whether to include passwords in e-mails.

Correct, but something you have turned a blind-eye to is if CompanyX have been using full password hashing (and thus not sending out passwords), what happens when they want to change their option to enable password sending? The answer is, nothing happens - the passwords are irrecoverably hashed.

This is a major security issue that needs to be addressed with highest priority!

It is the way SupportSuite (and eSupport) has worked for many, many years and it is generally accepted this is the only efficient way to go about it.

However, passwords should NEVER be stored in the clear and we have the option whether to include passwords in e-mails.

As long as your server is secure, there should be no problem. If it is a matter of trust between you and your client, then that is indeed between you and your client.

[Jamie Edwards]

Regardless of what I posted above, it is a good feature request that the option to use a "not entirely secure" encryption method for passwords be available.ave moved this thread into the Feature Requests forum.

[NC Software]

Passwords should never be sent in an e-mail, it should not be an option, but we do have the option to disable it. Passwords should NEVER be stored in plain text, EVER! Take not from vBulletin, they hash their information, if you have to reverse it out, encrypt it. Use SALT's as well for added security so dictionary attacks are mitigated. Again, do what vBulletin does, if you forget your password, it sends you a reminder question or simply changes it for you, when you login using the temp password you have to change it. There are ways to handle this, I adamately disagree with the lack of security I am finding with Kayako SupportSuite.

[Jamie Edwards]

Hi Neal,

This may be what you want, but the way SupportSuite has worked (for years - since the beginning) is that ticket passwords are sent out to customers in each ticket receipt. The majority of our customers do not disable this feature.

We cannot implement password hashing and have the option to either hash passwords or not.

Resetting the password in each ticket submission will also be a major inconvenience to users of a support desk.

Your comparison between a forum software and SupportSuite is entirely misplaced.

[Ryan Lederman]

Originally Posted by NC Software

Passwords should never be sent in an e-mail, it should not be an option, but we do have the option to disable it. Passwords should NEVER be stored in plain text, EVER! Take not from vBulletin, they hash their information, if you have to reverse it out, encrypt it. Use SALT's as well for added security so dictionary attacks are mitigated. Again, do what vBulletin does, if you forget your password, it sends you a reminder question or simply changes it for you, when you login using the temp password you have to change it. There are ways to handle this, I adamately disagree with the lack of security I am finding with Kayako SupportSuite.

Neal, I agree that it would be better to store say, MD5 fingerprints for users' passwords in the DB and if the event arose in which the user needed to reset the password, it would be randomly generated.

However, storing the passwords in the db with some form of two-way encryption isn't particularly viable. The reason is that the key(s) would be easily retrieved (where would you store them?) so even if it was encrypted, an attacker would only need to know the algorithm and the key and then it would be equivalent of having plain text passwords.

Just my two cents.

[Ryan Lederman]

In addition, I feel that it's necessary to address the whole idea of encrypting passwords in the db.

If your db is compromised you have much bigger problems on your hands than someone having access to the passwords. What I mean is, if an attacker has your db, he already has access to *all the information* that you would be worried about them accessing with the password (e.g. ticket posts, notes, etc)

[NC Software]

If your db is compromised you have much bigger problems on your hands than someone having access to the passwords. What I mean is, if an attacker has your db, he already has access to *all the information* that you would be worried about them accessing with the password (e.g. ticket posts, notes, etc)

I could care less if the attacker has my tickets, posts, notes, KB articles, download links, etc. But we all have a commitment to our users to protect their data, that is their e-mail addresses and passwords. This is IT 101, I know I don't need to convince you of this, it is standard practice in software.

[Brent]

I will agree this has me a bit distressed.....

[Chris Boulton]

Due to the nature of PHP as a language and platform, this would never be secure - it is unlike C++ (for example) which is obfuscated and then irreversibly (to an extent) compiled. Anyone with a copy of the software could easily decrypt the passwords if they got access to the database.

Of course, we could keep the code that does some form of encryption under the encrypted portion of SupportSuite, but again this is still not extremely secure. If a hacker is determined enough to hack your server, retrieve a copy of your database in order to access the client passwords, the likelihood is that he or she will be determined enough to reverse-engineer the algorithm.

I actually think this would be a pretty good solution to v4.

Essentially a custom encryption/decryption routine included within the encrypted part of SupportSuite. It could further be enhanced by the following:

• An additional "salt" field in the users table which stores a unique random string for each user which is also encrypted with the password when storing the password.
• A unique string per Kayako installation which is stored somewhere in the settings table or something, also thrown in to the mix when the encryption done.
• A private "key" held by Kayako which is also stored in part of the Zend/ionCube encoded part of SupportSuite

Should work fairly well.

[caitlyntw]

We've got this featured disabled. It is very odd Kayako has chosen to not protect customer passwords in their software design. I do not know another software or online site that does this.

Usually if customers forget password, they click on a link that allows them to either retrieve their password by answering a secret question or generate a new password.

[craigbrass]

Originally Posted by NC Software

I could care less if the attacker has my tickets, posts, notes, KB articles, download links, etc. But we all have a commitment to our users to protect their data, that is their e-mail addresses and passwords. This is IT 101, I know I don't need to convince you of this, it is standard practice in software.

Hmm yea, in the UK we are legally responsible for any data we collect. Something does need to be done to address this issue.

[Jamie Edwards]

Originally Posted by Chris Boulton

I actually think this would be a pretty good solution to v4.

Essentially a custom encryption/decryption routine included within the encrypted part of SupportSuite. It could further be enhanced by the following:

• An additional "salt" field in the users table which stores a unique random string for each user which is also encrypted with the password when storing the password.
• A unique string per Kayako installation which is stored somewhere in the settings table or something, also thrown in to the mix when the encryption done.
• A private "key" held by Kayako which is also stored in part of the Zend/ionCube encoded part of SupportSuite

Should work fairly well.

The idea is a sound one except that we cannot mislead customers to thinking the passwords will be secure. The 'hidden key' and 'encryption routine' would still be recoverable even if encoded with Zend or IonCube.

@Craig; that is true, you are legally responsible for this kind of thing; but this security requirement should be focused around your own server hardening. If passwords are to be encrypted, then why not everything in the database?

@Caitlyn; the reason why eSupport has not operated like 'most other software' in this respect is because the typical setup of eSupport (or the other lines) involved ticket submission via e-mail, which generated a password for the client in the ticket receipt.

However, times that change require us to change to, so it is something that will certainly be reviewed.