On 28.06.2011, at 14:26, Johannes Schlüter wrote: > On Tue, 2011-06-28 at 12:19 +0200, David Zülke wrote: > >> On 27.06.2011, at 01:55, Stas Malyshev wrote: >> >>> However, it still has a chance somebody's data won't work after the >>> update if he had 8-bit data hashed with old crypt(). He would need >>> either to re-hash or to change prefix from $2a to $2x. >> >> IMO that's a fair trade-off; people could even implement this in their >> app code by replacing "$2a" with "$2x" for a transitional period in >> the hash if the comparison fails (and then simply re-hash the password >> again with $2a so it's secure). I'm volunteering to write the >> necessary code sample for the upgrading notes :p > > if people read it ... what might happen is that people test when > upgrading (yay!) all tests and all work and then 1% of the users or so > can't login anymore (with an european site for instance where 8bit > characters might happen ...)
That might happen, but it isn't a critical issue I think since the change does not produce unconsumable hashes or silently corrupt data in some other way. I think you're also overestimating the amount of people using bcrypt for password storage; most people unfortunately still use SHA1s (with or without a salt). As Stas said though, whatever the upstream implementation uses as a solution should be mirrored by PHP. The alternative would be to introduce a new hash algorithm code that only works in newer versions of PHP, which hurts portability (which is the major selling point of crypt()). Simply "breaking" old hashes (there's not gonna be many of them out there) with the ability to easily and transparently fix it without user interaction in userland code seems like a much better idea to me. David
smime.p7s
Description: S/MIME cryptographic signature
