A hole in crypt_blowfish

Posted Jun 23, 2011 4:39 UTC (Thu) by nirbheek (subscriber, #54111)
In reply to: A hole in crypt_blowfish by bgilbert
Parent article: A hole in crypt_blowfish

Update library to fix bug, check password database for vulnerable passwords, mark them as having expired, and force the users to change it.

A hole in crypt_blowfish

Posted Jun 23, 2011 4:41 UTC (Thu) by nirbheek (subscriber, #54111) [Link]

Forgot to mention: the password vulnerability checking would need to be done at login-time. :)

A hole in crypt_blowfish

Posted Jun 23, 2011 10:18 UTC (Thu) by job (guest, #670) [Link] (4 responses)

Unless I miss something obvious, as soon as you update the library to hash high-bit passwords correctly the vulnerable passwords will not work anymore so there should be no need to expire them. (But please correct me if you've actually looked at it.)

A hole in crypt_blowfish

Posted Jun 23, 2011 21:15 UTC (Thu) by solardiz (guest, #35993) [Link] (3 responses)

From Owl change log and my announcement of crypt_blowfish 1.1: "... in some cases, alternate passwords may be found that would produce those same hashes under the correct algorithm. Thus, it is recommended that any passwords containing characters with the 8th bit set be changed after this upgrade."

Also, see comments by iabervon in here. And discussion on how to make it possible to upgrade transparently or safely: http://www.openwall.com/lists/oss-security/2011/06/23/3

A hole in crypt_blowfish

Posted Jun 23, 2011 23:44 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

any hash can have alternate inputs that produce the same output (and if the input is larger than the output, that is guaranteed to take place)

the fact that there are alternate inputs isn't the problem.

a hash is only considered broken if you can predict what inputs will produce a particular output.

In this case, that is exactly what happens, this bug means that someone can test far fewer inputs when trying to find one that matches the output, because you can predict that a large number of inputs will all produce the same output, and therefor only test one of them.

A hole in crypt_blowfish

Posted Jun 24, 2011 0:08 UTC (Fri) by solardiz (guest, #35993) [Link] (1 responses)

Indeed. However, I was commenting on the specific issue brought up earlier in the comment thread - namely, that not only is it practical to find colliding inputs for the broken hash, but also it is practical to find inputs to the correct(ed) hash that match those of the broken hash. Thus, some post-upgrade safety measures may be desired, such as treating passwords with '\xff' chars specially.

A hole in crypt_blowfish

Posted Jun 26, 2011 11:28 UTC (Sun) by job (guest, #670) [Link]

Thanks for the clarification.