Misc / General System -> Password encryption or hashing

[NC Software]

Craig,

You are obviously on "Team Kayako" as a tester which they offered me and I declined. What you may not realize is many of us here have been nothing less than violated. Our trust has been violated, we have been tremendously misled, we have been given false promises, and I could go on and on. Being treated this way and failing to deliver time after time after time does nothing but make customers irate. I have endured the absolute nonsense of "finding office space" "new 50 seat call center" and delay after delay in getting a decent solution that we paid for and expected. Kayako continues to fall on deaf ears, fails to do things to make the customer's job easier, case in point the lack of an "upgrade package" instead of a full download package so you don't overwrite graphics, config.php, etc. When we have to suffer with lost tickets due to tickets assigned to staff not belonging to departments, when our customers can't login due to case sensitive e-mail addresses, the mbstring fiasco, horrendous response from Kayako on support tickets (such as I submitted with the mbstring and never got an answer from the support system), to simple things as Kayako not using their own latest version and NEVER have just robs us of all confidence in this company. Version 3 has not lived up to its promises posted to this forum by Varun and company, and now you're talking about v4 which is an absolute joke! V3 has never really come out of BETA in my opinion, but that is only my opinion, and now you're talking v4. Whatever!

[craigbrass]

There is still no need to keep bashing Kayako in multiple topics. I have read 5-6 topics over the last week where you have done so.

Doing it once to make a point is fine, nothing wrong with that but as far as I am concerned, any more is just not needed. It just clutters up the board.

I feel that and many would agree with me that V3 has been a MASSIVE jump from V2. It has lived up to what was promised and it came out of beta stage at the end of 2005. There have been other small bugs but so does most software and Kayako have worked on these to the best of their ability.

[Jamie Edwards]

You are obviously on "Team Kayako" as a tester which they offered me and I declined.

This shows that from as early back as 2005, we have been proud to have you as a customer, Neal

[phillipfayers]

Originally Posted by Ryan Lederman

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

I'd say you need to address the idea of storing the passwords in the db.

Most environments have some kind of central authentication system and SupportSuite ought to be able to authenticate to that without storing the password at all.

At the moment there are a variety of modules which will authenticate to other systems (like AD or LDAP) - in those cases your database shouldn't store the password.

[bluesquares]

First off...I am so disappointed in the development team. I cannot believe you are not encrypting passwords in the database. This is a must in any kind of application. Even Joomla, Drupal, Wordpress and other free open source applications encrypt the passwords. Hell, there's even ZenCart and OSCommerce...free ecommerce engines that encrypt information in the DB!

Secondly, you are opening yourselves to serious legal ramifications. If an exploit is discovered in Kayako and databases are compromised, you will get the **** sued out of you. Just imagine the thousands of sites, emails, passwords and information that could potentially be revealed!

Finally, I'm not buying the cr*p about "we need to email the password and can't encrypt it". I'm calling total b*ll**** on that. It has become the norm for people to reset passwords and log in from scratch with random ones. It's also b*ll**** because I know for a fact that Coldfusion has the ability to encrypt into the database and decrypt at extraction. Are you telling me PHP can't do that?

Finally, I hope you realize that is you ever build an ecommerce ability into this shopping cart, you will need to make it VISA CISP compliant. And even the fools at VISA state...

• Password security settings support CISP-compliant password policies.
• All passwords and credit card numbers are encrypted.

C'mon. The safety and security of your clients and end-users should be at the top of this list. You best pray there aren't any vulnerabilities in the near future. They could cripple your future.

And yes....I'm pissed. Everything about this software is perfect. Except this.

[Jamie Edwards]

Hi bluesquares,

If you read through the thread, you will see there are very good reasons for not hashing the passwords like the software you mentioned (that do not encrypt passwords, they hash them).

You would also note that encrypting passwords in PHP software like ours, phpBBs or Drupals is useless - the encryption algorithm / secret key etc can be dug out of the PHP code even if it is encrypted. It would make things more difficult to recover passwords - yes - but if someone was determined enough to gain access to your database, they will be determined enough to find the key used to encrypt the passwords.

Also, we are not liable for any losses or compromises due to the security (or lack thereof) of a user's web server.

Finally, I'm not buying the cr*p about "we need to email the password and can't encrypt it". I'm calling total b*ll**** on that. It has become the norm for people to reset passwords and log in from scratch with random ones.

This is the way our ticketing software has always worked, and is a popular system - for the ticket key to be e-mailed to the user in each ticket receipt. Once again, this has already been discussed in this thread.

[hbidad]

You would also note that encrypting passwords in PHP software like ours, phpBBs or Drupals is useless - the encryption algorithm / secret key etc can be dug out of the PHP code even if it is encrypted. It would make things more difficult to recover passwords - yes - but if someone was determined enough to gain access to your database, they will be determined enough to find the key used to encrypt the passwords.

For crying out loud... that is the lamest thing I've heard. I wouldnt expect it from you.

To remind you how how crazy and unprofessional your response is:

yes - but if someone was determined enough to gain access to your House, they will be determined enough to pick the door lock or simply bust a window.

So I've been wasting my time by locking my door? Does everyone know how to pick a lock or is wanting to waste time learning how to? NO!!

In the same aspect, would the extra feature deter some script kiddies or if a db backup ended up in the wrong hands from seeing the passwords?

Your telling me you can't encrypt the key in a zend or ioncube encoded file? Cause it can be decrypted, it's not needed? Why do you waste your time encoding your Kayako source?

I think you used a poor example that wont set right with most people here.

Rant over

[bluesquares]

I rest my case. Taken from http://www.codinghorror.com/blog/archives/000949.html?

Passwords are never stored in plaintext. At least they shouldn't be, unless you're building the world's most insecure system using the world's most naïve programmers. Instead, passwords are stored as the output of a hash function. Hashes are one-way operations. Even if an attacker gained access to the hashed version of your password, it's not possible to reconstitute the password from the hash value alone.

[Jamie Edwards]

As I posted much earlier;

...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 ... [this] ...is something that will certainly be reviewed.

[NC Software]

Jamie,

You responses are quite disturbing. Rather than the "we do something unique or different, that's why we do this" is completely the wrong response, attitude, and the very reason companies get sued for negligence. You may "think" you can't get sued because it's the customer's responsibility, no, it's YOUR responsibility to protect the data you collect with your software. Does your EULA state that passwords are stored in plain text and therefore other measures to protect the database are required? Not all customers have the know how to view a DB schema or view the data directly to realize their information is vulnerable. They (we) expect competent companies and software developers to handle this properly.

There are ways to handle registrations, such as forcing an immediate password change on next visit if a temporary password is assigned. You have a INT column in the database that specifies the format of the password 0 - Plain Text 1 - Hashed 2 - Encrypted so when pulling that user record it knows how to decipher it. If it's 0 (Plain Text) then an immediate prompt is required at next login to create a password which is then hashed. There are ways of handling this, NONE of which are YOUR ways which again, is beyond disturbing.

You all are lucky, you have a role model to follow - vBulletin. They are the idol of all PHP developers and one of the most successful PHP products using MySQL ever developed. Do what they do, it's that simple!

Now how about handling this properly, maturely, and accept accountability AND communicate to your customers the vulnerability and what needs to be done to protect sensitive information as Kayako does not. This is eventually going to hit security advisor sites, e-Week, you name it, then you're going to have a real problem on your hand. Again, anyone can be sued, and if you do not properly handle what customers have brought to your attention, you are facing one heck of a fight.

Good luck!

[Jamie Edwards]

Neal,

Originally Posted by NC Software

Does your EULA state that passwords are stored in plain text and therefore other measures to protect the database are required?

No, it does not - the software is provided as is, and just like with the content of the tickets a user may receive that may be of a sensitive nature, it is up to them to protect it.

However, this does not mean we cannot make this easier for our users, which is why I have said (quoting again from my post above):

Originally Posted by Jamie Edwards

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

We have no concrete roadmap for this as of yet; but you can take that it will be a decision between hashing of the passwords or encrypting them.

[Ryan Lederman]

Like Jamie said, we WILL be addressing this problem. We are not ignoring it or you, the customers.

I personally would rather use a OWHF to store the passwords so that they are not retrievable. Like someone stated earlier, if the key and algorithm are known, it's not very hard to decrypt whatever has been encrypted.

If someone needs to "remember their password," well then they are just going to have to reset it. Tons of systems work this way and I feel it's better than actually storing a password in the database.

[Jamie Edwards]

Agree - although it is convenient to send the password in each receipt, times have changed; as will we.

[NC Software]

Originally Posted by Ryan Lederman

If someone needs to "remember their password," well then they are just going to have to reset it. Tons of systems work this way and I feel it's better than actually storing a password in the database.

Agreed Ryan - thanks for the post. I look forward to having this "done right" for your customers that do not keep their databases behind hardware firewalls, etc. There was a recent report on the hundreds of thousands of SQL Servers found exposed to the Internet, you know the same or more MySQL Servers are exposed. People don't know about internal networks, firewall usage, etc. We need fundamentals in the core software as the first defense.

[bear]

Thanks, Ryan, definitely a good thing to implement.
For those like me that didn't get the acronym straight away:
OWHF One-Way Hash Function (cryptography)