Re: todo: crypt_blowfish issue

2011/6/28 David Zülke <david.zuelke@bitextender.com>: > 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 > > > it would be good if we could communicate this change more than mentioning in the changelog. Tyrael