On Sun, Jul 17, 2011 at 04:29:15PM -0600, Joey Smith wrote: > On Sun, Jul 17, 2011 at 10:26:16PM +0400, Solar Designer wrote: > > + * For actual implementation, we set an array index in the variable "bug" > > + * (0 means no bug, 1 means sign extension bug emulation) and a flag in the > > + * variable "safety" (bit 16 is set when the safety measure is requested). > > + * Valid combinations of settings are: > > + * > > + * Prefix "$2a$": bug = 0, safety = 0x10000 > > + * Prefix "$2x$": bug = 1, safety = 0 > > + * Prefix "$2y$": bug = 0, safety = 0 > > If I'm understanding the change correctly, we should now be advising > users to transition their code to '$2y$' rather than '$2a$', with
Yes, but this is not terribly important. In practice, "$2a$" is almost the same as "$2y$". For passwords that don't contain the '\xff' character (which is not even valid in UTF-8 sequences), these two are 100% equivalent. For realistic passwords that do contain this character, I had one "hit" in 150,000+ such passwords tested: http://www.openwall.com/lists/oss-security/2011/07/08/1 So this is negligible, and even for the affected passwords (where "$2y$" and "$2a$" hashes differ by more than just the prefix) this only matters if those password hashes are ever migrated to other systems (non-PHP). The reason why I went for this is that I consider the security advantage of avoiding easy collisions with the buggy hashes non-negligible. > perhaps a note mentioning the '$2x$' prefix for "transitioning users > with passwords that contain non-ASCII characters with the 8th bit set". We need to be careful here such that no one starts using this for newly set passwords. This bit of documentation should be available to those few who actually need it (I expect that most sites won't care), but maybe it should not be on the function crypt() documentation page. > Obviously, any documentation change in this regard will need to be > pending on the version these patches get rolled into... Yes - need to release PHP versions with this code first. Thanks, Alexander -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
