|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #63549 Wrong commentary
Submitted: 2012-11-17 15:35 UTC Modified: 2012-11-19 04:41 UTC
From: varnavruz at gmail dot com Assigned:
Status: Wont fix Package: Documentation problem
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: varnavruz at gmail dot com
New email:
PHP Version: OS:


 [2012-11-17 15:35 UTC] varnavruz at gmail dot com
From manual page:
Page says:
Please refer to » this document for full details of the security fix, but to 
summarise, developers targeting only PHP 5.3.7 and later should use "$2y$" in 
preference to "$2a$".

But linked document ( says:
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 ... using $2y$ on 
newly set passwords.

So, this means that manual recommends backwards compatibility over security, not 
security and correctness over backwards compatibility for developers targeting 
only PHP 5.3.7 and later.
Why developers targeting only PHP 5.3.7 and later shall worry about insecure 
backwards compatibility?

Expected result:
Please remove the wrong recommendation to use $2y$ over $2a$


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2012-11-19 04:41 UTC]
To quote Solar Designer in bug #55477:

"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)."

We've gone around on this a bit (prompted by earlier bugs such as doc bug #62414) — at this point, the $2y$ recommendation seems like the best balance, since it retains the more secure behaviour but also backward compatibility.
 [2012-11-19 04:41 UTC]
-Status: Open +Status: Wont fix
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue May 28 00:01:32 2024 UTC