5 ms·

> All user passwords are salted, and hashed with the powerful bcrypt algorithm, which creates an irreversible hash which cannot be cracked While using bcrypt i

> All user passwords are salted, and hashed with the powerful bcrypt algorithm, which creates an irreversible hash which cannot be cracked While using bcrypt is great, it is not uncrackable. It is still vulnerable to brute force attacks. If you have a strong password it wont be cracked, but most people don't

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)?
Jgrubb 12y ago
Bcrypt question -- I thought that part of the strength of bcrypt was that it hashed password many, many times, and that number of times through the hash is based roughly on the strength of the CPU doing the hashing. If this is true, wouldn't that make it all but impossible to brute force? You'd have to know how many times the passwd was hashed in addition to everything else.
- chill1 12y ago
  bcrypt is a key derivation function based on the Blowfish cipher. The iteration count can be increased to make it slower, so it remains resistant to brute-force search attacks even with increasing computation power. The hash string includes the cost parameter, a salt, and the hash value. [1] This allows you to change the number of iterations and length of salt at any time, and all previously generated hashes will still be valid. It does not, however, adjust itself automatically depending upon the computational power of the computer on which it is running. [1] https://en.wikipedia.org/wiki/Bcrypt https://en.wikipedia.org/wiki/Bcrypt
- shawabawa3 12y ago
  > If this is true, wouldn't that make it all but impossible to brute force? The "key stretching" factor is configurable, but in the end you need to be able to check a login attempt in a reasonable amount of time (say, 1 second). So you have to be able to compute at least 1 hash/s on your production machine (probably much, much more to avoid performance problems). If the attacker has access to 100 machines as powerful as your production box for 6 months, they can calculate 100 * 86400 (seconds per day) * 180 (days per month) = 1.5 billion hashes. Depending on the value and strength of the passwords, this could be worth doing. It's almost certainly worth calculating the hashes of the top 100000 most common passwords in any case edit: > You'd have to know how many times the passwd was hashed in addition to everything else As chill1 said, that's usually stored along with the hash. Even if it wasn't, you could see how long login attempts took you to figure out a rough number, then just check the hash of every iteration up to say that number * 2
  - mike-cardwell 12y ago

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)?

Jgrubb 12y ago

Bcrypt question -- I thought that part of the strength of bcrypt was that it hashed password many, many times, and that number of times through the hash is based roughly on the strength of the CPU doing the hashing. If this is true, wouldn't that make it all but impossible to brute force? You'd have to know how many times the passwd was hashed in addition to everything else.

chill1 12y ago
bcrypt is a key derivation function based on the Blowfish cipher. The iteration count can be increased to make it slower, so it remains resistant to brute-force search attacks even with increasing computation power. The hash string includes the cost parameter, a salt, and the hash value. [1] This allows you to change the number of iterations and length of salt at any time, and all previously generated hashes will still be valid. It does not, however, adjust itself automatically depending upon the computational power of the computer on which it is running. [1] https://en.wikipedia.org/wiki/Bcrypt https://en.wikipedia.org/wiki/Bcrypt
shawabawa3 12y ago
> If this is true, wouldn't that make it all but impossible to brute force? The "key stretching" factor is configurable, but in the end you need to be able to check a login attempt in a reasonable amount of time (say, 1 second). So you have to be able to compute at least 1 hash/s on your production machine (probably much, much more to avoid performance problems). If the attacker has access to 100 machines as powerful as your production box for 6 months, they can calculate 100 * 86400 (seconds per day) * 180 (days per month) = 1.5 billion hashes. Depending on the value and strength of the passwords, this could be worth doing. It's almost certainly worth calculating the hashes of the top 100000 most common passwords in any case edit: > You'd have to know how many times the passwd was hashed in addition to everything else As chill1 said, that's usually stored along with the hash. Even if it wasn't, you could see how long login attempts took you to figure out a rough number, then just check the hash of every iteration up to say that number * 2
- mike-cardwell 12y ago