On Mon, Aug 22, 2011 at 04:01:46PM +0200, Pierre Joye wrote: > On Mon, Aug 22, 2011 at 3:52 PM, Solar Designer <so...@openwall.com> wrote: > >> On Mon, Aug 22, 2011 at 3:05 PM, Pierre Joye <pierre....@gmail.com> wrote: > >> > it seems that the changes break BC too, pls see > >> > https://bugs.php.net/bug.php?id=55477 > > > > We may recommend to Christian to change $2a$ in existing hashes to $2x$ if > > the goal is to preserve compatibility for all old passwords despite of > > the security risk associated with doing so. The change as implemented > > in PHP 5.3.7+ favors security and correctness over backwards compatibility, > > but it also lets users (admins of PHP app installs) use the new $2x$ > > prefix on existing hashes to preserve backwards compatibility for those > > and incur the associated security risk until all such passwords are > > changed (using $2a$ or $2y$ for newly changed passwords). > > > > No change to the PHP code is needed. > > Can you add this comment to the bug please? So every user reading it > will be informed. That's also something we have to document better.
I just did - I added a more verbose comment, though. I think you may use this for documentation: --- The change as implemented in PHP 5.3.7+ favors security and correctness over backwards compatibility, but it also lets users (admins of PHP app installs) use the new $2x$ prefix on existing hashes to preserve backwards compatibility for those and incur the associated security risk until all such passwords are changed (using $2a$ or $2y$ for newly changed passwords). In versions of PHP older than 5.3.7, $2a$ inadvertently resulted in system-specific behavior for passwords with non-ASCII characters in them. On some installs (mostly on PowerPC and ARM, as well as sometimes on *BSD's and Solaris regardless of CPU architecture), they were processed correctly. On most installs (most Linux, many others), they were processed incorrectly most of the time (but not always), and moreover in a way where security was weakened. In PHP 5.3.7, $2a$ results in almost the correct behavior, but with an additional countermeasure against security-weakened old hashes mentioned above. $2x$ results in the buggy behavior, so if old hashes are known to be of the buggy type, this may be used on them to keep them working, accepting the associated security risk. $2y$ results in perfectly correct behavior (without the countermeasure), so it may be used (if desired) when hashing newly set passwords. For practical purposes, it does not really matter if you use $2a$ or $2y$ for newly set passwords, as the countermeasure is only triggered on some obscure passwords (not even valid UTF-8) that are unlikely to be seen outside of a deliberate attack (trying to match hashes produced by buggy pre-5.3.7 code). BTW, PHP 5.3.7+ has been updated to crypt_blowfish 1.2, not the intermediate 1.1 release referenced in the previous comment. The differences between 1.1 and 1.2 include introduction of the countermeasure for $2a$ mentioned above and the $2y$ prefix. Summary: for passwords without characters with the 8th bit set, there's no issue, all three prefixes work exactly the same. For occasional passwords with characters with the 8th bit set, if the app prefers security and correctness over backwards compatibility, no action is needed - just upgrade to new PHP and use its new behavior (with $2a$). However, if an app install admin truly prefers backwards compatibility over security, and the problem is seen on the specific install (which is not always the case because not all platforms/builds were affected), then $2a$ in existing hashes in the database may be changed to $2x$. Alternatively, a similar thing may be achieved by changing $2a$ to $2x$ in PHP app code after database queries, and using $2y$ on newly set passwords (such that the app's automatic change to $2x$ on queries is not triggered for them). --- BTW, the discrepancy in formatting for comment preview and actually posted comments is nasty. Alexander -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
