Why is SHA-256 not good for passwords?

Question

I've just started learning about all of this and I can't really find an answer for that anywhere, namely why is SHA-256 not used for passwords? I found that the reason is that because normal SHA-256 is a fast function, and it's better to use slower ones, but here's the part i don't really get, from what i've read so far, SHA-256 produces a hash that'd take A LOT of years to crack, like A LOT A LOT, so why is it considered bad for passwords when it's basically impossible to crack?

Answer 1

It's all about reducing the overall risk of loss. A good hash algorithm makes it impossible to reverse the hash value to compute the original text. However, passwords are very, very short. By making a guess at a password, the attacker can compare the output of his SHA-256 against the SHA-256 that he finds in the database. And because passwords are so short, testing many password guesses this way is easy for a computer. For a few thousand dollars you can build a small supercomputer dedicated to SHA-256 testing (similar to those used for bitcoin mining), which enables an attacker to test 16 trillion different password guesses per second. That is much more effective than trying to break SHA-256.

Hashing passwords is not about trying to prevent the cracking of any one single password. Web site owners are much more concerned because they have a database of a million users, and when attackers break in, they frequently steal a copy of the database of passwords. They want to make it hard for the attacker to break all of the passwords in their database.

Most attackers are motivated by money, and they aren't dedicated to breaking just one specific account's password. They run a brute force attack against the whole database. If one user has the password of abc123, and it's kept as a SHA-256 hash, then they get one account. But if a thousand users all have that same password, they get a thousand accounts. And the case is often that 20-50% of the accounts in a database have very easy-to-guess passwords. In a million account database, that might mean they can crack half a million accounts.

With the dedicated hardware (or an array of botnet zombies) an attacker can easily break a large number of passwords in a typical database when they are only protected by a single iteration of SHA-256. And breaking passwords on one site enables attackers to take advantage of people who reuse their passwords on multiple sites. This is a precursor to performing Account Take Over (ATO) attacks, where they reuse the stolen passwords on other sites to access bank accounts or gift cards, and steal actual money.

To defend against this, a purpose-built password protecting algorithm is designed as a time-waster. For example, PBKDF2 executes a hash algorithm like SHA-256 hundreds, thousands, or millions of times, depending on how you configure it. This increases the amount of work that an attacker needs to do to execute a single test by that large factor. If you set PBKDF2 to execute a million iterations, that would reduce the effectiveness of the box above to testing only 16 million password guesses per second per account. An attacker would only be able to test a millionth of the passwords in the database when compared to cracking a database where they were stored as single SHA-256 bit hashes. That's the risk reduction.

Answer 2

In addition to John's excellent answer, there's another important thing to consider.

When checking a password, a lot of time is spent in actions like looking up the stored account information (username, password) in a database.

If you have a fast hashing algorithm, that lookup now takes up a significant portion of your password validation. This makes it relatively easy for an intruder to do an attack where he just fires off random names and passwords and determines which names rather than passwords don't exist by timing the responses.

By slow hashing the incoming password before sending it to the database for comparison with the stored password, you're taking the duration of the database lookup and password comparison themselves out of the time needed for checking passwords. Result is that a failed lookup now takes the same time (within margin for network latency etc.) as a successful one.

Of course this assumes you hash the incoming password before trying to retrieve the user information. If you don't, a fail for a non-existent user would be a lot faster than a fail for an existing user with a bad password, giving the person doing an attack on your system potential information about which of the attempts he made contained actual usernames, even if he didn't know those were actual usernames to begin with.

Does this happen in practice? No idea. But that was one reason for slow hashing mechanisms our pentest team told us several years ago.