I have been seeing recommendations to use bcrypt to hash passwords because of its ability to keep up with Moore's Law.
Apparently the reason for this is because it would take much longer for an attacker to crack a bcrypt hash than a hash generated by a general purpose hash function like SHA256.
How is that possible? How can an algorithm be deliberately slow in spite of Moore's law?
Data security systems that rely on MD5 can be easily hacked by anyone with a basic understanding of the function. On the other hand, bcrypt is not broken. As a result, it's still able to keep passwords and information safe. Modern passwords should never be stored behind MD5.
BCrypt is based on the Blowfish block cipher cryptomatic algorithm and takes the form of an adaptive hash function.
BCrypt Algorithm is used to hash and salt passwords securely. BCrypt permits building a password security stage that can advance nearby hardware innovation to guard against dangers or threats in the long run, like attackers having the computing power to guess passwords twice as quickly.
Another benefit of bcrypt is that it requires a salt by default. Let's take a deeper look at how this hashing function works! "`bcrypt` forces you to follow security best practices as it requires a salt as part of the hashing process.
bcrypt is configurable with a parameter called "work factor". Internally, it will perform an operation which is similar to hashing, many times successively. The "many" is the part that can be configured, up to several billions. So, to cope with Moore's law, just crank up that setting. Another function which can be made as slow as wanted is PBKDF2 (see the "iteration count" parameter).
Note that the point of making the password hashing slow is to make things difficult for the attacker, but it also mechanically makes things slow for the "honest systems" too; that's a trade-off. See this answer (on security.stackexchange) for more details.
An attacker will want to try all 216,553 english words.
Plus another 12 bits of effort for the common variations, which lets say gives a list of 887,001,088 (229) possible passwords.
BCrypt takes about 4,342,912 (i.e. 222) operations to calculate one hash (at cost=12).
A core today provides about 231 cycles/sec; the state of the art is 8 = 23 cores per processor for a total of 23 * 231 = 234 cycles/sec. A server typically has 4 processors, increasing the total to 22 * 234 = 236 cycles/sec. 222 cycles to calculate one hash * 229 possible (common) passwords = 251 cycles to run through all (common) passwords.
This means that it would take a 4-processor, octo-core, server about 251 / 236 = 215 seconds (9 hours) to run through all common passwords.
In reality my password is not common, and uses about 44-bits. 244 passwords * 222 cycles per password = 266 cycles to try all uncommon passwords. 266 / 236 cycles/second = 230 seconds (34 years) to find my password.
Moore's Law's says the processing power doubles every 18 months.
That's now bcrypt holds up against Moore's Law.
Increase the cost factor from 12 to 13 and that will double the times involved.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With