oss-sec mailing list archives
Re: CVE request: crypt_blowfish 8-bit character mishandling
From: Solar Designer <solar () openwall com>
Date: Mon, 20 Jun 2011 19:19:13 +0400
On Mon, Jun 20, 2011 at 02:56:28PM +0000, The Fungi wrote:
Would it make sense to include transitional compatability calls which preserve the original behavior?
Maybe, but this sounds worse than my "$2x$" proposal, which allows for the same and more (it also lets one access the backwards compat functionality without patching any code, by patching the hash encodings in a database instead). If an app knows what it is doing (and you're talking solely about such apps above), it can simply replace 'a' with 'x' before its call to crypt() or the like.
Then applications using the library can be adjusted to fall back on the buggy version if the supplied data has 8-bit characters and the corrected calls don't result in a match.
This doubles the CPU time that a DoS attacker can consume per authentication attempt, thereby halving the maximum iteration count that an admin can reasonably set for new password hashes to use. On the other hand, if the iteration count was set significantly below the affordable maximum for whatever reason, which is the common case, then this is acceptable. Then there's also the remotely measurable timing difference, but that leak may be acceptable (telling an observer roughly what goes on).
This would allow tools to regenerate and replace non-conforming hashes if they were the result of this bug, and might make it easier to audit existing lists for them as well.
This is possible with my proposal as well. The difference is that with your proposal all hashes would remain listed as "$2a$", and only the affected ones would be replaced (still remaining at "$2a$", which is important not to leak any extra info about the passwords via the hash encodings). However, if one wants to implement your approach (or similar), they can do so via my proposed interface (with "$2x$") as well, by changing the 'a' to 'x' for just one function call (rather than in the database). The choice is theirs. That said, I appreciate you posting this suggestion, and I'd be happy to consider some more. It is always possible that there's some brilliant idea I had not thought of... Thanks, Alexander
Current thread:
- CVE request: crypt_blowfish 8-bit character mishandling Solar Designer (Jun 19)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Daniel Godás (Jun 20)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Solar Designer (Jun 20)
- Re: CVE request: crypt_blowfish 8-bit character mishandling The Fungi (Jun 20)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Solar Designer (Jun 20)
- Re: CVE request: crypt_blowfish 8-bit character mishandling The Fungi (Jun 20)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Solar Designer (Jun 21)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Josh Bressers (Jun 21)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Solar Designer (Jun 20)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Daniel Godás (Jun 20)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Ludwig Nussel (Jun 21)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Solar Designer (Jun 21)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Ludwig Nussel (Jun 22)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Solar Designer (Jun 23)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Solar Designer (Jun 23)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Ludwig Nussel (Jun 27)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Michael Matz (Jun 27)