問題描述
這個問題與 PHP 對 crypt().對于這個問題，salt 的前 7 個字符不計算在內(nèi)，所以一個 salt '$2a$07$a' 會被說成長度為 1，因為它只是 salt 的 1 個字符和 7 個元數(shù)據(jù)字符.
This question has to do with PHP's implementation of crypt(). For this question, the first 7 characters of the salt are not counted, so a salt '$2a$07$a' would be said to have a length of 1, as it is only 1 character of salt and seven characters of meta-data.
當(dāng)使用長度超過 22 個字符的 salt 字符串時，生成的哈希值沒有變化(即截斷)，當(dāng)使用長度小于 21 個字符的字符串時，salt 將自動填充(使用 '$' 字符，顯然)；這是相當(dāng)簡單的.但是，如果給定一個salt 20 個字符和一個salt 21 個字符，其中除了長度為21 的salt 的最后一個字符之外，兩者是相同的，那么兩個散列字符串將是相同的.一個22個字符長的salt，除了最后一個字符與21個長度的salt相同，hash會再次不同.
When using salt strings longer than 22 characters, there is no change in the hash generated (i.e., truncation), and when using strings shorter than 21 characters the salt will automatically be padded (with '$' characters, apparently); this is fairly straightforward. However, if given a salt 20 characters and a salt 21 characters, where the two are identical except for the final character of the 21-length salt, both hashed strings will be identical. A salt 22 characters long, which is identical to the 21 length salt except for the final character, the hash will be different again.
代碼示例:
$foo = 'bar';
$salt_xx = '$2a$07$';
$salt_19 = $salt_xx . 'b1b2ee48991281a439d';
$salt_20 = $salt_19 . 'a';
$salt_21 = $salt_20 . '2';
$salt_22 = $salt_21 . 'b';
var_dump(
crypt($foo, $salt_19),
crypt($foo, $salt_20),
crypt($foo, $salt_21),
crypt($foo, $salt_22)
);
將產(chǎn)生:
string(60) "$2a$07$b1b2ee48991281a439d$$.dEUdhUoQXVqUieLTCp0cFVolhFcbuNi"
string(60) "$2a$07$b1b2ee48991281a439da$.UxGYN739wLkV5PGoR1XA4EvNVPjwylG"
string(60) "$2a$07$b1b2ee48991281a439da2.UxGYN739wLkV5PGoR1XA4EvNVPjwylG"
string(60) "$2a$07$b1b2ee48991281a439da2O4AH0.y/AsOuzMpI.f4sBs8E2hQjPUQq"
這是為什么?
有些用戶注意到整個字符串存在差異，這是真的.在salt_20中，offset(28, 4)為da$.，而在salt_21中，offset(28, 4)為da2.;但是，需要注意的是，生成的字符串包括哈希值、鹽值以及生成鹽值的指令(即 $2a$07$)；事實上，發(fā)生差異的部分仍然是鹽.實際哈希值保持不變，為 UxGYN739wLkV5PGoR1XA4EvNVPjwylG.
Some users are noting that there is a difference in the overall string, which is true. In salt_20, offset (28, 4) is da$., while in salt_21, offset (28, 4) is da2.; however, it is important to note that the string generated includes the hash, the salt, as well as instructions to generate the salt (i.e. $2a$07$); the part in which the difference occurs is, in fact, still the salt. The actual hash is unchanged as UxGYN739wLkV5PGoR1XA4EvNVPjwylG.
因此，這實際上不是生成的散列的差異，而是用于存儲散列的鹽的差異，這正是手頭的問題:兩個鹽生成相同的散列.
Thus, this is in fact not a difference in the hash produced, but a difference in the salt used to store the hash, which is precisely the problem at hand: two salts are generating the same hash.
Rembmer:輸出將采用以下格式:
Rembmer: the output will be in the following format:
"$2a$##$saltsaltsaltsaltsaltsaHASHhashHASHhashHASHhashHASHhash"
// ^ Hash Starts Here, offset 28,32
其中## 是 log-base-2 決定算法運行的迭代次數(shù)
where ## is the log-base-2 determining the number of iterations the algorithm runs for
在評論中，有人要求我發(fā)布一些附加信息，因為用戶無法重現(xiàn)我的輸出.執(zhí)行以下代碼:
In the comments, it was requested that I post some additional info, as the user could not reproduce my output. Execution of the following code:
var_dump(
PHP_VERSION,
PHP_OS,
CRYPT_SALT_LENGTH,
CRYPT_STD_DES,
CRYPT_EXT_DES,
CRYPT_MD5,
CRYPT_BLOWFISH
);
產(chǎn)生以下輸出:
string(5) "5.3.0"
string(5) "WINNT"
int(60)
int(1)
int(1)
int(1)
int(1)
希望這會有所幫助.
推薦答案
經(jīng)過一些實驗，我得出的結(jié)論是，這是由于鹽的處理方式造成的.salt 不被認(rèn)為是文字文本，而是一個 base64 編碼的字符串，這樣 22 字節(jié)的 salt 數(shù)據(jù)實際上代表了一個 16 字節(jié)的字符串 (floor(22 * 24/32) == 16) 鹽.明白了！"但是，使用此實現(xiàn)，就像 Unix crypt 一樣，它使用非標(biāo)準(zhǔn)"base64 字母表.準(zhǔn)確地說，它使用這個字母表:
After some experimentation, I have come to the conclusion that this is due to the way the salt is treated. The salt is not considered to be literal text, but rather to be a base64 encoded string, such that 22 bytes of salt data would actually represent a 16 byte string (floor(22 * 24 / 32) == 16) of salt. The "Gotcha!" with this implementation, though, is that, like Unix crypt, it uses a "non-standard" base64 alphabet. To be exact, it uses this alphabet:
./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789$
第 65 個字符$"是填充字符.
The 65th character, '$', is the padding character.
現(xiàn)在，crypt() 函數(shù)似乎能夠采用小于或等于其最大值的任何長度的鹽，并通過丟棄任何不符合要求的數(shù)據(jù)來靜默處理 base64 中的任何不一致.不構(gòu)成另一個完整字節(jié).如果你在 salt 中傳遞不屬于它的 base64 字母表的字符，crypt 函數(shù)將完全失敗，這正好證實了它的操作理論.
Now, the crypt() function appears to be capable of taking a salt of any length less than or equal to its maximum, and silently handling any inconsistencies in the base64 by discarding any data that doesn't make up another full byte. The crypt function will fail completely if you pass it characters in the salt that are not part of its base64 alphabet, which just confirms this theory of its operation.
取一個假想的鹽1234".這與 base64 完全一致，因為它表示 24 位數(shù)據(jù)，即 3 個字節(jié)，并且不攜帶任何需要丟棄的數(shù)據(jù).這是一個 Len Mod 4 為零的鹽.將任何字符附加到該鹽上，它就變成了一個 5 個字符的鹽，并且 Len Mod 4 現(xiàn)在是 1.但是，這個額外的字符只代表 6 位數(shù)據(jù)，因此不能轉(zhuǎn)換為另一個完整的字節(jié)，因此被丟棄.
Take an imaginary salt '1234'. This is perfectly base64 consistent in that it represents 24 bits of data, so 3 bytes, and does not carry any data that needs to be discarded. This is a salt whose Len Mod 4 is zero. Append any character to that salt, and it becomes a 5 character salt, and Len Mod 4 is now 1. However, this additional character represents only six bits of data, and therefore cannot be transformed into another full byte, so it is discarded.
因此，對于任意兩種鹽 A 和 B，其中
Thus, for any two salts A and B, where
Len A Mod 4 == 0
&& Len B Mod 4 == 1 // these two lines mean the same thing
&& Len B = Len A + 1 // but are semantically important separately
&& A == substr B, 0, Len A
crypt() 用于計算散列的實際鹽實際上是相同的.作為證明，我提供了一些可用于展示這一點的示例 PHP 代碼.鹽以半非隨機方式不斷旋轉(zhuǎn)(基于當(dāng)前時間到微秒的漩渦散列的隨機片段)，以及要散列的數(shù)據(jù)(此處稱為 $種子) 只是當(dāng)前的 Unix-Epoch 時間.
The actual salt used by crypt() to calculate the hash will, in fact, be identical. As proof, I'm including some example PHP code that can be used to show this. The salt constantly rotates in a seminon-random way (based on a randomish segment of the whirlpool hash of the current time to the microsecond), and the data to be hashed (herein called $seed) is simply the current Unix-Epoch time.
$salt = substr(hash('whirlpool',microtime()),rand(0,105),22);
$seed = time();
for ($i = 0, $j = strlen($salt); $i <= $j; ++$i) {
printf('%02d = %s%s%c',
$i,
crypt($seed,'$2a$07$' . substr($salt, 0, $i)),
$i%4 == 0 || $i % 4 == 1 ? ' <-' : '',
0x0A
);
}
這會產(chǎn)生類似于以下的輸出
And this produces output similar to the following
00 = $2a$07$$$$$$$$$$$$$$$$$$$$$$.rBxL4x0LvuUp8rhGfnEKSOevBKB5V2. <-
01 = $2a$07$e$$$$$$$$$$$$$$$$$$$$.rBxL4x0LvuUp8rhGfnEKSOevBKB5V2. <-
02 = $2a$07$e8$$$$$$$$$$$$$$$$$$$.WEimjvvOvQ.lGh/V6HFkts7Rq5rpXZG
03 = $2a$07$e89$$$$$$$$$$$$$$$$$$.Ww5p352lsfQCWarRIWWGGbKa074K4/.
04 = $2a$07$e895$$$$$$$$$$$$$$$$$.ZGSPawtL.pOeNI74nhhnHowYrJBrLuW <-
05 = $2a$07$e8955$$$$$$$$$$$$$$$$.ZGSPawtL.pOeNI74nhhnHowYrJBrLuW <-
06 = $2a$07$e8955b$$$$$$$$$$$$$$$.2UumGVfyc4SgAZBs5P6IKlUYma7sxqa
07 = $2a$07$e8955be$$$$$$$$$$$$$$.gb6deOAckxHP/WIZOGPZ6/P3oUSQkPm
08 = $2a$07$e8955be6$$$$$$$$$$$$$.5gox0YOqQMfF6FBU9weAz5RmcIKZoki <-
09 = $2a$07$e8955be61$$$$$$$$$$$$.5gox0YOqQMfF6FBU9weAz5RmcIKZoki <-
10 = $2a$07$e8955be616$$$$$$$$$$$.hWHhdkS9Z3m7/PMKn1Ko7Qf2S7H4ttK
11 = $2a$07$e8955be6162$$$$$$$$$$.meHPOa25CYG2G8JrbC8dPQuWf9yw0Iy
12 = $2a$07$e8955be61624$$$$$$$$$.vcp/UGtAwLJWvtKTndM7w1/30NuYdYa <-
13 = $2a$07$e8955be616246$$$$$$$$.vcp/UGtAwLJWvtKTndM7w1/30NuYdYa <-
14 = $2a$07$e8955be6162468$$$$$$$.OTzcPMwrtXxx6YHKtaX0mypWvqJK5Ye
15 = $2a$07$e8955be6162468d$$$$$$.pDcOFp68WnHqU8tZJxuf2V0nqUqwc0W
16 = $2a$07$e8955be6162468de$$$$$.YDv5tkOeXkOECJmjl1R8zXVRMlU0rJi <-
17 = $2a$07$e8955be6162468deb$$$$.YDv5tkOeXkOECJmjl1R8zXVRMlU0rJi <-
18 = $2a$07$e8955be6162468deb0$$$.aNZIHogUlCn8H7W3naR50pzEsQgnakq
19 = $2a$07$e8955be6162468deb0d$$.ytfAwRL.czZr/K3hGPmbgJlheoZUyL2
20 = $2a$07$e8955be6162468deb0da$.0xhS8VgxJOn4skeI02VNI6jI6324EPe <-
21 = $2a$07$e8955be6162468deb0da3.0xhS8VgxJOn4skeI02VNI6jI6324EPe <-
22 = $2a$07$e8955be6162468deb0da3ucYVpET7X/5YddEeJxVqqUIxs3COrdym
結(jié)論?雙重.首先，它按預(yù)期工作，其次，了解你自己的鹽或不滾你自己的鹽.
The conclusion? Twofold. First, it's working as intended, and second, know your own salt or don't roll your own salt.
這篇關(guān)于為什么 crypt/blowfish 使用兩種不同的鹽生成相同的哈希?的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網(wǎng)！