Making a Hash of Passwords
Source: J.F. Rice
After so many high-profile data breaches, it’s time developers learned that storing passwords is a really bad idea. And there is a perfectly workable alternative.
Last week, I went to a project meeting so I could provide security insights as some consulting software developers updated us on the customer-facing application they’re building for us. But I was dumbfounded when they asked me, “How should we encrypt the passwords?” Will developers never learn?
This ebook offers ten key considerations when moving to a cloud-based contact center. What are your
Learn More
It could well be that the developers thought I would be impressed that they were thinking about security. After all, they wanted to encrypt the passwords their database would collect. I’m sorry to say, though, that I didn’t feel like patting them on the back. That’s because the question that occurred to me was, “Why would you think it’s a good idea to collect passwords at all?” The entire interaction took me back 10 years, and it distressed me to think that, despite all the high-profile data breaches we’ve seen since then, not much has changed.
Even 10 years ago, when software developers would ask data security practitioners how they should encrypt the passwords, we would respond, “You don’t.” The best practice that was then coming into focus was to avoid storing sensitive data provided by customers such as passwords and credit card numbers. You didn’t need to store it; you could just validate it.
For passwords, it works like this. Users have to type in their username and password every time they log in. What we need to do is to take that password and hash it (compute a unique value using a hashing algorithm like MD5 or SHA), and compare that hash value to a hash value that your application previously stored in its database. If the hash values match, then the user has typed in the right password. This method eliminates the need for storing passwords. The application only needs to take the data entered into the password field and run a hash computation on it in real time, nothing further.
A decade ago, we were using the MD5 hashing algorithm. These days, MD5 is obsolete, so we use the SHA-2 algorithm instead, but the result is the same. When I wrote about this recently I called hashing a “tried-and-true technique” for developing authentication systems. I figured that by now, everyone would be doing it.
That’s why I was surprised, even shocked, that today’s developers are asking how to encrypt passwords for storage. They are still trying to save the user’s password in their databases, so they can decrypt them and compare the actual password value entered by the user to the stored password, instead of comparing hash values. This is crazy. Any database that contains passwords can be compromised, thereby disclosing all its passwords.
And this does keep happening. LinkedIn, eBay, Twitter and others have all lost passwords in the last couple of years, and a Russian gang has reportedly collected over 1.2 billion passwords from all over the place. Are we really still storing passwords in this day and age? Am I the only one telling people not to do that?
I sent the developers home with a new assignment: Don’t store passwords. Store hash values instead. They understood right away, saw it was a good idea, and agreed to do it that way. And I hope word gets around, because I hate to think we are perpetuating bad practices in the most important part of our software, the login.
| }
|