4 ms·

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 bas

by 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
  If you've slowed somebody down to brute forcing only 1.5 billion hashes in 6 months by using bcrypt, you have been overwhelmingly successfull. This system here can brute force 180 billion MD5 hashes per second: http://www.zdnet.com/25-gpus-devour-password-hashes-at-up-to-348-billion-per-second-7000008368/ http://www.zdnet.com/25-gpus-devour-password-hashes-at-up-to... [edit] If you only allow passwords to contain upper/lower case letters and numbers, at 1.5 billion MD5 hashes per 6 months, it would take 19 years to check up to and including 6 character long passwords. And because it's bcrypt, and each password has a different salt, you need to do that for each user; you can't build up a raintable as you go.

by Jgrubb 12y ago

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
If you've slowed somebody down to brute forcing only 1.5 billion hashes in 6 months by using bcrypt, you have been overwhelmingly successfull. This system here can brute force 180 billion MD5 hashes per second: http://www.zdnet.com/25-gpus-devour-password-hashes-at-up-to-348-billion-per-second-7000008368/ http://www.zdnet.com/25-gpus-devour-password-hashes-at-up-to... [edit] If you only allow passwords to contain upper/lower case letters and numbers, at 1.5 billion MD5 hashes per 6 months, it would take 19 years to check up to and including 6 character long passwords. And because it's bcrypt, and each password has a different salt, you need to do that for each user; you can't build up a raintable as you go.