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?

  • 1
    SHA256 is pretty good to use in e.g. PBKDF2. It's just that a single round of plain SHA256 is easily computable to brute-force passwords. – Archimedix Oct 12 '18 at 6:20
  • 2
    It does depend on how strong the passwords you are trying to protect are. If the password is password12345 the SHA256 hash can be broken by just searching for it on Google. If the password was SIk2xq2L5Mk3eAtWan1xlNzgQab2BgW4 it would have been perfectly safe to protect it with SHA256. If the password is strong enough even MD5 would be safe. Nobody is going to find out which password I hashed to get 16fbe9fc4e489610f290128030d2ebac. But for mediocre passwords there is a lot of security to be gained from using a strong iterated salted hash. – kasperd Oct 12 '18 at 9:29

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 buy a small supercomputer dedicated to SHA-256 testing (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.

With the dedicated hardware (or an array of botnet zombies) an attacker can easily break the vast majority of passwords in a typical database where 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 to access bank accounts or gift cards, and steal actual money.

To defend against this, a purpose-built password protecting algorithm is built as a time-waster. For example, PBKDF2 executes a hash algorithm 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. An attacker would only be able to break a millionth of the passwords in the database when compared to cracking a database where they were stored as single SHA-256. That's the risk reduction.

  • do note that almost all commercial miners can't be used to crack passwords, they can only mine. GPUs are another story... – dandavis Oct 12 '18 at 17:01
  • @dandavis very true, but the point is still true that testing guesses is fast and cheap. – John Deters Oct 12 '18 at 17:13

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.

  • 4
    By slow hashing the incoming password before sending it to the database - it's recommended to use salted passwords (for various reasons), so the normal order of operation would be the other way around (retrieve the hashed password and the salt, then apply an algorithm to the incoming password to check it). Also, welcome to the infosec stack! – Ethan Kaminski Oct 12 '18 at 7:02
  • Yes, this is a strategy that is in use. The common name of this technique is “anchor dragging”. – John Deters Oct 12 '18 at 17:06
  • @EthanKaminski true, so do we. Same principle though, you don't want the different branches to take dissimilar amounts of time depending on when they fail – jwenting Oct 13 '18 at 3:57

Not the answer you're looking for? Browse other questions tagged or ask your own question.