|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2013-12-14 01:05 UTC] jan at zahlen-kern dot de
Description:
------------
The password_hash() function accepts raw salt strings through the $options parameter, but it fails to encode them correctly. As a result, the hash is different than it would be with common bcrypt.
This is caused by an incorrect encoding procedure: The function applies standard Base64, removes the padding and replaces "+" with ".". This does yield the right alphabet, but in the Base64 variant used by bcrypt, the digits have different values:
Common Base64 is
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
bcrypt Base 64 is
./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789
So the function effectively adds 2 modulo 64 to every salt byte. The last salt digit in the resulting hash is correct, though, because the current bcrypt implementation internally fixes it.
Test script:
---------------
<?php
$salt = str_repeat("\x00", 22);
echo password_hash('foo', PASSWORD_BCRYPT, array('salt' => $salt));
Expected result:
----------------
The resulting hash should be
"$2y$10$......................0li5vIK0lccG/IXHAOP2wBncDW/oa2u"
Actual result:
--------------
Instead, it is
"$2y$10$AAAAAAAAAAAAAAAAAAAAA.A6.6PO3Wv4OxvTWdUxMVpdLT2d5g/FG"
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Sat Dec 21 13:01:31 2024 UTC |
It's not a problem of pre-encoded salts. If the salt only contains Base64 digits (which is the case for alphanumeric strings), it will be passed straight to crypt(). The bug occurs when the library tries to convert a binary salt into Base64. This happens in two places: -- If the salt is generated automatically -- If you specify a custom salt which does not only contain Base64 digits The first case isn't visible from the outside. While the library does pass an "impossible" salt to crypt(), the current bcrypt implementation fixes this. That's why we don't see the bug in the resulting hash. Without this error correction, we would in fact get nonsensical hashes at all times. The second case can be verified with any salt that does not only contain Base64 digits. For example: $password = 'foo'; $cost = 10; $salt = str_repeat("\x01", 22); // we actually only need 16 bytes $hash = password_hash($password, PASSWORD_BCRYPT, array('salt' => $salt)); Expected result: "$2y$10$.OC/.OC/.OC/.OC/.OC/.OgAsrO3gl0RHNcFPE3BIzZ1Bz0qZsc6K" Actual result: "$2y$10$AQEBAQEBAQEBAQEBAQEBAO7r8cBYh78G83ccYofvR5QAV0LN00wTu" Also note that the last salt digit is "O" instead of "Q". This is due to the error correction. The author of the extension has already acknowledged the wrong encoding in the context of the password_compat library (which is a PHP implementation of the API).