Bcrypt for password hashing because it is slow?

Question

I read today on not-implemented.com :

Sha-256 should be chosen in most cases where a high speed hash function is desired. It is considered secure with no known theoretical vulnerabilities and it has a reasonable digest size of 32 bytes. For things like hashing user password, though, a function designed to be slow is preferred: a great one is bcrypt.

Can somebody explain the last sentence :

For things like hashing user password, though, a function designed to be slow is preferred: a great one is bcrypt.

I don't say it's not correct, my question is simply:

Why it is preferred for hashing user password to use a slow function ?

Solution 1

Because if it takes more time to hash the value, it also takes a much longer time to brute-force the password.

Keep in mind that slow means that it requires more computing power. The same goes for when a potential hacker tries to brute-force a password.

Solution 2

On your side, the password hash needs to be computed rather rarely. But an attacker who tries to brute force a password from a stolen hash, relies on computing as many hashes as possible.

So, if your login now takes 100 ms instead of 0.1 (probably less) that's not really a problem for you. But it makes a huge difference for an attacker if he needs 2000 days to break a password instead of 2 days.

bcrypt is designed to be slow and not to allow any shortcut.

Solution 3

It takes more effort to brute force attack the password. The slower the algorithm, the less guesses can be made per second. The extra time won't be noticed by a user of the system, but will make it harder to crack the password.