A Better Way to Store Password Hashes?
1–10 of 59 posts
Re: A Better Way to Store Password Hashes?
#2The problem is, even with the salted hash, it’s still too easy for an attacker to run dictionary attacks if they are able to retrieve a single user’s salt and hash. When your attacker can do 1 billion SHA1 hashes/second with cheap hardware, even slowing it down 10,000 times and they’re still cracking a lot of your users’ passwords.
False. If you use Colin Percival's scrypt to hash your passwords, then it's impossible for an attacker to crack them via brute force.
See previous discussion: http://news.ycombinator.com/item?id=4076197
Re: A Better Way to Store Password Hashes?
#3Or just use bcrypt/scrypt/PBKDF2 in the typical manner. You're much more likely to screw yourself by mis-implementing this than you are to actually gain any real security benefit from it.
Re: A Better Way to Store Password Hashes?
#4[deleted]
Re: A Better Way to Store Password Hashes?
#5The problem is, even with the salted hash, it’s still too easy for an attacker to run dictionary attacks if they are able to retrieve a single user’s salt and hash. When your attacker can do 1 billion SHA1 hashes/second with cheap hardware, even slowing it down 10,000 times and they’re still cracking a lot of your users’ passwords. False. If you use Colin Percival's scrypt to hash your passwords, then it's impossible…
It's certainly not impossible. scrypt provides reasonable defense against using cheap highly parallel approaches to brute force, but still can obviously be cracked by brute force.
For passwords, current typical attacker does not care about cracking all of them, but cares about finding some (mostly weak) passwords that he can try with other services used by same user.
Re: A Better Way to Store Password Hashes?
#6The problem is, even with the salted hash, it’s still too easy for an attacker to run dictionary attacks if they are able to retrieve a single user’s salt and hash. When your attacker can do 1 billion SHA1 hashes/second with cheap hardware, even slowing it down 10,000 times and they’re still cracking a lot of your users’ passwords. False. If you use Colin Percival's scrypt to hash your passwords, then it's impossible…
I am the author of the article. Thanks for pointing out scrypt, I have heard of it before. PBKDF2, bcrypt, scrypt... they all share one thing in common:
They MUST be configured to run fast enough on your server so that your users can login even under high system load.
Let's say you need to support being able to test 1,000 passwords per second on your server (to support your projected peak login traffic). In that case, relatively weak passwords can be cracked, and by relatively weak I mean 95th percentile entropy bits for less than $1,000 on EC2.
This is why I'm trying to think differently about the problem. If we hide the hash in a haystack, the attacker will no longer be able to target an individual user, and theft of the entire hash database should be more easily detectable and preventable.
Re: A Better Way to Store Password Hashes?
#7I am skeptical that this method adds any protection to a brute force attack relative to a standard implementation of PBKDF2 hashes stored with the users.
With proper salts, we have no advantage cracking a password in a database of 10 users or 10 million users. LinkedIn didn't have any salts.
The effectiveness of brute forcing a password is determined entirely by how many passwords they can test for a particular user (because they are salted) in a given period of time. Sure you can add tens of gigabytes of extra data that they have to search through, but your system has to search through it too so it's no different than adding extra iterations to PBKDF2.
Re: A Better Way to Store Password Hashes?
#8The problem is, even with the salted hash, it’s still too easy for an attacker to run dictionary attacks if they are able to retrieve a single user’s salt and hash. When your attacker can do 1 billion SHA1 hashes/second with cheap hardware, even slowing it down 10,000 times and they’re still cracking a lot of your users’ passwords. False. If you use Colin Percival's scrypt to hash your passwords, then it's impossible…
I am the author of the article. Thanks for pointing out scrypt, I have heard of it before. PBKDF2, bcrypt, scrypt... they all share one thing in common: They MUST be configured to run fast enough on your server so that your users can login even under high system load. Let's say you need to support being able to test 1,000 passwords per second on your server (to support your projected peak login traffic). In that case…
_Nobody_ is hashing thousands of passwords per second as part of a typical webapp load. Even if somebody was, they would need only ~50 cores for hashing. I'm sure anybody with that much traffic could easily shell out a few thousand bucks for the extra processors without blinking.
Also, an 8 character password hashed with scrypt with a very low (64ms) cost takes on average $4.8 million to brute force[1].
Re: A Better Way to Store Password Hashes?
#9I am skeptical that this method adds any protection to a brute force attack relative to a standard implementation of PBKDF2 hashes stored with the users. With proper salts, we have no advantage cracking a password in a database of 10 users or 10 million users. LinkedIn didn't have any salts. The effectiveness of brute forcing a password is determined entirely by how many passwords they can test for a particular user…
It's a question of sizing up what resources the attacker has, versus what they will need to succeed in an attack.
We want to make password cracking extremely difficult. It's a problem a big site should want to throw some money at.
Today, we make it hard by requiring lots of CPU. Another commenter said 'scrypt' -- yes, we want to make it hard by requiring lots of RAM too.
Here's another way to make it hard -- now you'll need to make a clean getaway with multiple TBs of data off my server too, just to hopefully steal ONE user's password.
There is a benefit here, I think.
Re: A Better Way to Store Password Hashes?
#10I am skeptical that this method adds any protection to a brute force attack relative to a standard implementation of PBKDF2 hashes stored with the users. With proper salts, we have no advantage cracking a password in a database of 10 users or 10 million users. LinkedIn didn't have any salts. The effectiveness of brute forcing a password is determined entirely by how many passwords they can test for a particular user…
It's a question of sizing up what resources the attacker has, versus what they will need to succeed in an attack. We want to make password cracking extremely difficult. It's a problem a big site should want to throw some money at. Today, we make it hard by requiring lots of CPU. Another commenter said 'scrypt' -- yes, we want to make it hard by requiring lots of RAM too. Here's another way to make it hard -- now you'…
Ok, requiring the attacker to download several terabytes could be an interesting advantage. Could we also achieve that by inserting billions of fake users in a traditional [user, salt, hash] setup?