Recently the hashing collision issue of SHA-1 was discovered. Identical hash values for 2 separate PDF files were generated. Does that make SHA-1 any unsafe for using it only for password hashing?. The probability of two different password to match is still negligible, right?

  • $\begingroup$ From all these answers my conclusion is: The password hashing algorithm is better if it is slow in computing, and other different parameters. The very distant probability of collision has less effect in password hashing. Is my conclusion correct? $\endgroup$
    – Rohith K D
    Apr 8 '17 at 19:17

SHA-1 in itself was never safe for password hashing. The hash algorithm itself doesn't have a work factor parameter nor does it have a salt as input. These are requirements for run-of-the-mill passwords that do not have as much security as a good symmetric key.

For this reason password hash algorithms have been invented, also known as password based key derivation functions (PBKDF). The difference between a password hash and a PBKDF is mainly how the result is used: directly as a password hash to compare with a stored password hash or as symmetric key for input in a symmetric cipher or MAC algorithm.

Well known password hash algorithms are PBKDF2, bcrypt, scrypt and of course the already mentioned Argon2. The latter two also contain options for configuring memory hardness, to overcome hardware based attacks.

The above functions can often be configured using a hash function. For instance PBKDF2 requires a secure hash as configuration parameter, and it (kinda) defaults to SHA-1.

As long as SHA-1 doesn't have direct collisions it could still be secure for this purpose. Even if there were collisions, it is unlikely that this would compromise the security of a password database.

Due to the high number of iterations it is even less likely that a password hash is reversed, i.e. that the one-way property of the total hash doesn't hold. This property is of course the most important one for the password hash.

For this reason it's probably OK to keep SHA-1 as configuration parameter for some specific password hash algorithms that require it.

However attacks just get better, never worse. So if possible, even in the above scenario, you should move away from SHA-1 to SHA-2/SHA-3. Or choose a password hash function that doesn't rely on a secure hash at all.


While you are technically correct and finding pre-images for SHA-1 is still nowhere in sight it would still be prudent and clearer to just not use it.

Possible attacks aside it was never a great choice for hashing passwords anyway. There are more specialized hashes for that with specific properties like being slow to compute and thus slowing down dictionary attacks.

Look at things like Argon2 and the password hashing competition.


The published attack was a collision attack which does not directly affect the security of password hashing in any reasonable security scenario. With password hashing we are primarily interested in preimage attacks and we may know a lot about the plain text. The recent collision didn't actually add much in the way of cryptanalysis we new SHA-1 had weaknesses for several years. Regardless of any cryptanalytic weakness SHA-1 is less useful for password hashing on account of it being very fast. This makes brute forcing the password which comes from a space far smaller then all possible SHA-1 inputs far easier. That said, if you use a large salt and apply SHA-1 many times over and over again to slow it down it is fairly secure for password hashing IMHO. On the flip side there is no advantage to doing this over using bcrypt which was and is the recommded way to hash passwords.


While there is nothing wrong to use SHA-1 for password hashing (thus short inputs) at the moment (2017) and for the next very few years (by that I mean that you passwords are probably still secure), it is not advised.

The reason for that is the advances in Crypto will make it weaker and weaker. The following graph illustrate the advances in search of Collision.

enter image description here [source]

We can currently compute collisions on MD5 in a matter of seconds. You can expect this to be the case in the future for SHA-1.

So instead of using a weakened algorithm, you can directly opt for the safe and standard ones (such as SHA-3).

  • 1
    $\begingroup$ SHA-1 was never on its own a good function for password hashing. See Maarten's answer. $\endgroup$ Apr 7 '17 at 17:41
  • $\begingroup$ Plus points for the hash image and it's source, minus points for stating "there is nothing wrong to use SHA-1 for password hashing". It's plain wrong. Please read this. $\endgroup$
    – Mast
    Apr 8 '17 at 9:32
  • 1
    $\begingroup$ Also, collisions are not a problem for typical password hashing scenarios. So the above graph has little relevance for this problem. I'd expect there to be little practical difference between iterated MD5, SHA1 and SHA256 when you adjust the iteration count to result in the same cost of the defender's system. $\endgroup$ Apr 8 '17 at 10:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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