Hi!
On 6/26/11 4:31 PM, Pierre Joye wrote:
hi!
I did not read the report, do you have the details about the breakage?
It could be acceptable in 5.3.
The problem is that if the string has 8-bit chars in it, the hash
ignores certain characters, making the password much less secure and
generating high quantity of collisions. It also makes it incompatible
with OpenBSD hashing, which may be lesser problem, depending on the use,
and likely is, since nobody reported it beforehand.
The solution implemented in the original patch and 5.4 is to fix the new
hash and introduce a new hash type (starting with $2x and not with $2a
as regular blowfish hash) that would use old, buggy hash type. This
allows people that need to have password compatibility to have it at the
cost of modifications on their data (which is possible without knowing
the original passwords since only the prefix changes), while keeping the
algorithm secure.
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.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
