| |||||||||||||
A hole in crypt_blowfishA hole in crypt_blowfishPosted Jun 22, 2011 20:15 UTC (Wed) by iabervon (subscriber, #722)Parent article: A hole in crypt_blowfish
The bug means that, when a non-ascii character is reached, any characters earlier in the current block of 4 characters are replaced with char 255. One possibility would be to simply reject any attempt to use a password containing char 255, which would make any password containing a non-ascii character hashed with the old code impossible to type, and effectively invalidate the passwords that were affected. Alternatively, the function could replace any char 255 with a char 127, based on the fact that no common encoding uses both of these (so it's not interesting to confuse them), and get the same effect without prohibiting any newly-entered passwords.
(Log in to post comments)
A hole in crypt_blowfish Posted Jun 22, 2011 21:22 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link] I'm not sure I follow. Suppose my password was "ab£", as given in the article. With this bug, someone could log in as me with simply "£", or "xy£". If you have a corrected library and are generating fresh hashes, no prohibition on char 255 or any high-bit-set character is necessary. If you're trying to let in folks with high-bit-set characters and old hashes (so that they can fix their passwords), the char 255 restriction achieves nothing. What was your goal again?
A hole in crypt_blowfish Posted Jun 22, 2011 22:20 UTC (Wed) by iabervon (subscriber, #722) [Link]
My goal is to invalidate all and only the weak passwords, by making it such that, if this bug affected an old password, no string could be given to the fixed code in order to give that hash.
If you had set your password to "ab£", the hash actually stored would be the proper hash of "ÿÿ£". If an attacker typed "xy£" or simply "£", the hash they got would also be the proper hash of "ÿÿ£". If the code is fixed, the only way to type your password would be "ÿÿ£", but this would work for any of the other passwords saved with the buggy code as well, so those passwords are still weak. However, when the bug is fixed, the only way to type any password whose saved hash was weakened by the bug is to use "ÿ". So it would invalidate weak passwords if using "ÿ" became impossible, either by simply rejecting it or by replacing it with some other value.
A hole in crypt_blowfish Posted Jun 22, 2011 22:44 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link]
Ah, gotcha. You're not trying to gracefully grandfather in those whose passwords are affected. Rather, you're simply forcing their passwords to be invalid once you have the corrected library.
That leaves the process of "how do you securely reset the affected users' passwords" as an exercise to be solved by the reader. ;-)
|
|||||||||||||