php.net |  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
Have you experienced this issue?
Rate the importance of this bug to you:

 [2012-11-17 15:35 UTC] varnavruz at gmail dot com
Description:
------------
---
From manual page: http://www.php.net/function.crypt#refsect1-function.crypt-
description
---
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 (http://www.php.net/security/crypt_blowfish.php) 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$


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-11-19 04:41 UTC] aharvey@php.net
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] aharvey@php.net
-Status: Open +Status: Wont fix
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu May 30 18:01:33 2024 UTC