Date: Mon, 20 Jun 2011 19:19:13 +0400 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: Re: CVE request: crypt_blowfish 8-bit character mishandling 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
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ