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?

  • security.stackexchange.com/questions/211/…
    – pm1391
    Commented Oct 12, 2018 at 3:29
  • 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.
    – Arc
    Commented Oct 12, 2018 at 6:20
  • 3
    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
    Commented Oct 12, 2018 at 9:29

2 Answers 2


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.

  • do note that almost all commercial miners can't be used to crack passwords, they can only mine. GPUs are another story...
    – dandavis
    Commented Oct 12, 2018 at 17:01
  • @dandavis very true, but the point is still true that testing guesses is fast and cheap. Commented Oct 12, 2018 at 17:13
  • How is it feasible to store the millionth hash of a password? You are going to do the same when checking whether a password entered by a user is correct.
    – Wais Kamal
    Commented Apr 10, 2023 at 1:48
  • @WaisKamal, that's correct. To check a password against the value in the database, you have to hash their entry a million times. That's the price you pay to improve the security. Commented Aug 12, 2023 at 21:35

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.

  • 5
    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!
    – Soron
    Commented Oct 12, 2018 at 7:02
  • Yes, this is a strategy that is in use. The common name of this technique is “anchor dragging”. Commented Oct 12, 2018 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
    Commented Oct 13, 2018 at 3:57

Not the answer you're looking for? Browse other questions tagged .