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$
$\endgroup$
0
Add a comment
|
4 Answers
$\begingroup$
$\endgroup$
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.
answered Apr 7, 2017 at 10:08
Maarten Bodewes - on strike♦Maarten Bodewes - on strike
90.2k13 gold badges156 silver badges309 bronze badges
$\begingroup$
$\endgroup$
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.
$\begingroup$
$\endgroup$
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.
$\begingroup$
$\endgroup$
3
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.
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, 2017 at 17:41
-
-
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, 2017 at 10:46