3 ms·

Can you explain this in more detail? As a crypto noob I have always used bcrypt to hash the password concatenated with a unique salt for that password and store

by bgdam 12y ago

Can you explain this in more detail? As a crypto noob I have always used bcrypt to hash the password concatenated with a unique salt for that password and stored the hash in my db. Is this no longer sound advice?

icebraining 12y ago
I think the point is that if someone choose "12345" as their password, the best hash in the world can't protect it, since it's trivial to try a few combinations and hit on the right password. Strong hashes prevent bruteforcing millions of combinations, but that actually depends on the attacker needing to try millions of combinations.
bigiain 12y ago
So look at the passwords they admit to being compromised. One of them is "nakula". Look at who signed the postmortem as "founders". Google Nakul and find out his surname is "Aggarwal". If you were guessing Browserstack admin passwords hoping to find a weak one - how long would it take you to try "nakula"? No choice of bcrypt/scrypt/pbkdf2 hashing is going to protect against trivially guessable passwords...
shawabawa3 12y ago
No, it's still best practice. The problem is it's impossible to protect weak passwords, because attackers can just run a password database through your hashing algorithm and see if there are any matches. i.e. Just because you can't reverse a hash to get the password, doesn't mean you can't hash a bunch of passwords to figure out which leads to which hash
- wastedhours 12y ago
  Thanks for making that point - that's been going around my head for a few weeks whilst pondering on password encryption. Rainbow table attacks are still more than possible with all of these algorithms when used on their own? So salts are certainly the way to go, as, although they're "known" (appended to hash, or stored elsewhere in DB), the hash can't be compared to a generic table, it'd need to be a full dictionary table of hashes already encrypted with that salt (which theoretically/hopefully is used only once)?

by bgdam 12y ago

icebraining 12y ago

I think the point is that if someone choose "12345" as their password, the best hash in the world can't protect it, since it's trivial to try a few combinations and hit on the right password. Strong hashes prevent bruteforcing millions of combinations, but that actually depends on the attacker needing to try millions of combinations.

bigiain 12y ago

So look at the passwords they admit to being compromised. One of them is "nakula". Look at who signed the postmortem as "founders". Google Nakul and find out his surname is "Aggarwal". If you were guessing Browserstack admin passwords hoping to find a weak one - how long would it take you to try "nakula"? No choice of bcrypt/scrypt/pbkdf2 hashing is going to protect against trivially guessable passwords...

shawabawa3 12y ago

No, it's still best practice. The problem is it's impossible to protect weak passwords, because attackers can just run a password database through your hashing algorithm and see if there are any matches. i.e. Just because you can't reverse a hash to get the password, doesn't mean you can't hash a bunch of passwords to figure out which leads to which hash

wastedhours 12y ago
Thanks for making that point - that's been going around my head for a few weeks whilst pondering on password encryption. Rainbow table attacks are still more than possible with all of these algorithms when used on their own? So salts are certainly the way to go, as, although they're "known" (appended to hash, or stored elsewhere in DB), the hash can't be compared to a generic table, it'd need to be a full dictionary table of hashes already encrypted with that salt (which theoretically/hopefully is used only once)?