I was attempting to re-implement the ASP.NET Identity password hash algorithm in PHP. It uses RFC 2898, which uses HMAC SHA1. SHA1 has been broken by google. Does this mean that RFC 2898 in general and the current ASP.NET Identity password hash format in particular are broken?
$\begingroup$
$\endgroup$
6
-
$\begingroup$ You will probably ease answering if you change RFC 2898 to PBKDF2 which is far more common name. $\endgroup$– axapaxaCommented May 18, 2017 at 11:51
-
4$\begingroup$ HMAC-SHA1 is still safe and this use-case doesn't even suffer from collision attacks anyways. $\endgroup$– SEJPMCommented May 18, 2017 at 12:17
-
$\begingroup$ @axapaxa edited the title thanks. It was a surprise early this morning. $\endgroup$– Justin DearingCommented May 18, 2017 at 12:23
-
1$\begingroup$ Still worth making clear that PBKDF2 is a general construction; even if a SHA-1 vulnerability did have an effect on PBKDF2-HMAC-SHA1, it wouldn't mean anything for PBKDF2-HMAC-SHA3 or any other flavor. $\endgroup$– hobbsCommented May 18, 2017 at 17:02
-
$\begingroup$ Dupe crypto.stackexchange.com/questions/26510/… and crypto.stackexchange.com/questions/18575/is-hmac-sha-1-secure and nearly crypto.stackexchange.com/questions/9336/… $\endgroup$– dave_thompson_085Commented Jun 30, 2018 at 1:41
|
Show 1 more comment
1 Answer
$\begingroup$
$\endgroup$
2
That particular usage of SHA-1 uses HMAC, and then iterates that as part of PBKDF2 (which is actually defined for any PRF, not just HMAC-SHA1).
As of this date (2017-05-18) HMAC-SHA1 is unbroken in terms of collisions and other attacks, so PBKDF2-HMAC-SHA1 is still considered safe. The HMAC construction, along with the many iterations in PBKDF2, protects against the Google collision attack on SHA1.
However, new applications should move to at least SHA2-256 or SHA3-256 as a hashing primitive and not implement anything using SHA1 at all unless strictly necessary for compatibility with other systems.
In your case, you need compatibility with older systems, so go ahead, but build in code and make a transition plan to use newer hash function in the near future. Adding simple version field alongside the password hash will suffice in most cases.
-
1$\begingroup$ In PBKDF2 using HMAC with SHA-1 as PRF, the PBKDF2 password is the HMAC key (exclusively), and as part fo the specification of HMAC, when that password/key is larger than an SHA-1 message block (64 bytes), it is hashed using SHA-1 before use in HMAC. It follows that colliding SHA-1 messages as obtained by Google's attacks are also equivalent passwords for PBKDF2-HMAC-SHA-1. This is an odd fact, but I still agree with the answer, since the PBKDF2 password is supposed to be secret. [reposted with yet another tweak after the 5mn deadline] $\endgroup$– fgrieu ♦Commented May 18, 2017 at 16:12
-
2$\begingroup$ @fgrieu: In any case, the same quirk of HMAC also means that, for any hash H and any string s longer than the block size of H, s and H(s) are equivalent HMAC-H keys, and therefore equivalent passwords for PBKDF2-HMAC-H. So you don't actually need the SHA1 collision to construct equivalent passwords. $\endgroup$ Commented May 18, 2017 at 16:18