Far too frequently, systems are hacked and their user databases are compromised. And there are far too many cases where the database contains plain text passwords, poorly hashed passwords, or two-way encrypted passwords, despite the wealth of resources available on how to properly store user credentials. And it’s not just legacy databases; just this week, I saw a reddit thread with at least one developer advocating custom hashing functions and “security through obscurity”.
Though cryptography is a complex subject, you don’t need to be an expert to be a good steward of your users’ credentials. Just follow these simple rules when selecting a scheme:1
- Use a proven one-way hashing algorithm that has been publicly reviewed by security experts, such as bcrypt, PBKDF2, or scrypt.
- Don’t attempt to write your own hashing algorithm. You can’t rely on “security by obscurity”; you must assume the attacker has your source code, and can attack your inferior algorithm.2
- I mean it, don’t write your own hashing algorithm! Just use one of the ones from Rule #1. They are free, available on virtually any platform, and have been proven secure by the best minds in security.
- Seriously, why are you even still reading this? Rule #1 is all you need!
- Alright, if you are really going to ignore Rule #1, please at least notify your users that you are not safely storing their passwords, and in the event of a database breach, their passwords will become public knowledge.
I don’t like to deal in absolutes, particularly in software development, but I truly feel strongly about this. There is no situation in which you should be developing your own password hashing algorithm!3 Here’s an example of using PBKDF2 in Java without importing any external libraries; if Node.js is your thing, there’s a module for bcrypt; there’s a Ruby gem for scrypt; hell, even PHP has a built-in password hashing function that uses bcrypt. Really, virtually any language has a freely available library for any of those three algorithms. Just Google “your-language-of-choice bcrypt OR scrypt OR pbkdf2” and you’ll find plenty of options.
Any hash function that has not been through rigorous public peer review is almost certainly not properly designed. If Niels Provos himself — one of the creators of bcrypt — was on my team and wanted to use a new hash function he created in private, I would pass on it and use bcrypt. Although I doubt Mr. Provos would be foolish enough to suggest using such an algorithm; he may have created the next great password hashing algorithm, but he would likely realize that it could not be relied upon until it had been evaluated by his fellow security experts.
So when you need to store user credentials, just please, please hash them with bcrypt, scrypt, or PBKDF2. It’s easy. Don’t try to be clever.
- 1 Even better: don’t store user credentials if you don’t have to. Consider using an OAuth provider, or your organization’s internal identity system. It saves some effort, and saves your users from remembering yet another set of credentials.↩
- 2 This is essentially Kerckhoff’s principle: “The system must not require secrecy and can be stolen by the enemy without causing trouble”↩
- 3 Okay, I suppose if you are entering something like the Password Hashing Competition or doing academic research, that’s fine. But you still shouldn’t be using it in a real application until it has been through thorough public review.↩
| Reference: | 5 simple rules for securely storing passwords from our JCG partner Jerry Orr at the Jerry on Java blog. |
