Ask HN: How should I store passwords?
I've been told to "use bcrypt", but is bcrypt really all that stronger?
All the arguments I have seen in favor of it simply argued that it is good because it's slower than crippled molasses going uphill in January, but with a well-secured NoSQL and a properly rate-limited login system, is that really necessary?
I've been looking at SHA-512 with multiple salts, but what do you use or suggest I do?
EDIT: Just an FYI, we're a startup that will be dealing mostly in accounts of the social network variety. We will deal a bit in financial info, but mostly just user data.
15 comments
[ 4.1 ms ] story [ 70.7 ms ] threadYou can control how slow bcrypt is by specifying the wok factor variable. In this context "slow" is maybe 100ms to check a password. This shouldn't be a problem on almost any web site.
Use bcrypt.
Am I still risking bcrypt being cryptographically broken?
I don't think the concern is so much hacking your login than it is what happens if someone grabs your user table.
That said, I suspect what you are proposing is stronger than average even among the HN crowd.
Use bcrypt. It upper bounds the loss of your database at somewhere below "Most of my users get their email accounts and bank accounts compromised."
Age does not matter. In many cases, youth can even be beneficial, since it can include more modern techniques.
Talk to tptacek about this if you think NoSQL means No SQL Injections So I'm OK.
You site might be just a simple "social network site, nothing serious like banks", but loads of people use the same password for their email. Once you have someone's email password, you have the keys to the kingdom.
It (currently) doesn't seem likely that either bcrypt or SHA-something are going to be busted open by a flaw in the algorithm.
On the other hand, the fact that bcrypt has a large work-load makes it significantly less likely to be broken by someone running a cluster of GPU-equipped EC2 instances.
Let me ask it this way: What reason do you have for not using bcrypt considering everyone seems to suggest it? Do you worry that it's too slow? Or that the implementation is weak? Or something else?
I also worry that it's not really as "future-proof" as people seem to think. Every algorithm gets busted open eventually, given Moore's Law, they can try more ways faster. Plus, once we have quantum computing, all the cryptographic algorithms we know and love are busted wide open. Hell, AES has been busted already in quantum computing!
The NSA created SHA-512. They are in the middle of choosing a successor, implying that SHA-512 isn't good enough any more and it's time to have a backup.
The Wikipedia page ( http://en.wikipedia.org/wiki/SHA-512 ) lists some cryptographic flaws, which implies it's time to start retiring it.
SHA-512 is plenty big enough to require age-of-the-universe-scale CPU-effort to crack. For what it was designed for. But it simply wasn't designed for storing short bits of text like passwords. Anyone using it for that is using it wrongly, and has built a system that is far, far more prone to cracking than the theoretical strength of SHA-512 suggests.
Once you go beyond even basically competent crypto, the only thing that matters is how fast you can try likely passwords.
For passwords, SHA-512 is no better than MD5, because though MD5 has theoretical issues, no sane person will ever do a math attack on MD5 to crack your password, when they can just try all combinations of likely passwords in a few seconds or minutes.
And SHA-512 is no better than MD5 if I can try passwords at the same rate. Because I'm going to guess your password in the same amount of time. Even if you had a SHA-65536. The only practical reason SHA-512 is better for passwords than MD5 is that it takes a good chunk longer to calculate (but not long enough!).
So it is the rate of hashing, not the 'power' of the algorithm you need to worry about. And that is why bcrypt is what you should use. It isn't that it is stronger crypto, strength is irrelevant: it is slower crypto. And that's what you need when you're handling passwords.
As for 'we have a secure db and rate limited login' - why not use plaintext passwords then? SHA based hashing is only a few days CPU more secure than plaintext for short passwords. In both cases you're banking on nobody having access to the database. If you can guarantee nobody has access to the database, and you're rate limiting your logins, then why not use plaintext? No. You use password hashing explicitly because you can't guarantee db security. So use the right tool for the job.
tl;dr - Use bcrypt, it is many orders of magnitude more secure than SHA-2-based approaches.