A hole in crypt_blowfish

Posted Jun 22, 2011 19:28 UTC (Wed) by martinfick (subscriber, #4455)
Parent article: A hole in crypt_blowfish

> Requiring that users change their existing passwords after logging in is an alternative, but one that might give attackers a window in which to operate. It also leaves passwords unchanged for any users that do not log in.

Seems like another alternative would be to simply lazily update the stored hash on login since the unencrypted password is available then. This way users would not be forced to change their passwords.

A hole in crypt_blowfish

Posted Jun 22, 2011 20:01 UTC (Wed) by mjthayer (guest, #39183) [Link] (9 responses)

> Seems like another alternative would be to simply lazily update the stored hash on login since the unencrypted password is available then. This way users would not be forced to change their passwords.
If I understood correctly, someone who had managed to grab an old copy of the password database and who used it to find one of the "alternative" versions of an affected password might be able to use it to find the real one more easily.

A hole in crypt_blowfish

Posted Jun 22, 2011 20:27 UTC (Wed) by dark (guest, #8483) [Link] (8 responses)

There's a more drastic solution: don't allow characters with the high bit set in passwords at all. Deny login to any attempts to log in with such passwords.

The users will have to get their passwords changed, but this will be limited to users who were affected by the bug, and there's no window of opportunity for attackers.

One would hope this approach is coupled with a plan to phase out the restriction, though :)

A hole in crypt_blowfish

Posted Jun 22, 2011 22:18 UTC (Wed) by bgilbert (subscriber, #4738) [Link] (7 responses)

The restriction could exclude passwords that were set after the bug had been fixed.

A hole in crypt_blowfish

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

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.