問題描述
這個(gè)問題與 PHP 對(duì) crypt().對(duì)于這個(gè)問題，salt 的前 7 個(gè)字符不計(jì)算在內(nèi)，所以一個(gè) salt '$2a$07$a' 會(huì)被說(shuō)成長(zhǎng)度為 1，因?yàn)樗皇?salt 的 1 個(gè)字符和 7 個(gè)元數(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)使用長(zhǎng)度超過 22 個(gè)字符的 salt 字符串時(shí)，生成的哈希值沒有變化(即截?cái)?，當(dāng)使用長(zhǎng)度小于 21 個(gè)字符的字符串時(shí)，salt 將自動(dòng)填充(使用 '$' 字符，顯然)；這是相當(dāng)簡(jiǎn)單的.但是，如果給定一個(gè)salt 20 個(gè)字符和一個(gè)salt 21 個(gè)字符，其中除了長(zhǎng)度為21 的salt 的最后一個(gè)字符之外，兩者是相同的，那么兩個(gè)散列字符串將是相同的.一個(gè)22個(gè)字符長(zhǎng)的salt，除了最后一個(gè)字符與21個(gè)長(zhǎng)度的salt相同，hash會(huì)再次不同.
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"
這是為什么?
有些用戶注意到整個(gè)字符串存在差異，這是真的.在salt_20中，offset(28, 4)為da$.，而在salt_21中，offset(28, 4)為da2.;但是，需要注意的是，生成的字符串包括哈希值、鹽值以及生成鹽值的指令(即 $2a$07$)；事實(shí)上，發(fā)生差異的部分仍然是鹽.實(shí)際哈希值保持不變，為 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.
因此，這實(shí)際上不是生成的散列的差異，而是用于存儲(chǔ)散列的鹽的差異，這正是手頭的問題:兩個(gè)鹽生成相同的散列.
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 決定算法運(yùn)行的迭代次數(shù)
where ## is the log-base-2 determining the number of iterations the algorithm runs for
在評(píng)論中，有人要求我發(fā)布一些附加信息，因?yàn)橛脩魺o(wú)法重現(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)
希望這會(huì)有所幫助.
推薦答案
經(jīng)過一些實(shí)驗(yàn)，我得出的結(jié)論是，這是由于鹽的處理方式造成的.salt 不被認(rèn)為是文字文本，而是一個(gè) base64 編碼的字符串，這樣 22 字節(jié)的 salt 數(shù)據(jù)實(shí)際上代表了一個(gè) 16 字節(jié)的字符串 (floor(22 * 24/32) == 16) 鹽.明白了！"但是，使用此實(shí)現(xiàn)，就像 Unix crypt 一樣，它使用非標(biāo)準(zhǔn)"base64 字母表.準(zhǔn)確地說(shuō)，它使用這個(gè)字母表:
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 個(gè)字符$"是填充字符.
The 65th character, '$', is the padding character.
現(xiàn)在，crypt() 函數(shù)似乎能夠采用小于或等于其最大值的任何長(zhǎng)度的鹽，并通過丟棄任何不符合要求的數(shù)據(jù)來(lái)靜默處理 base64 中的任何不一致.不構(gòu)成另一個(gè)完整字節(jié).如果你在 salt 中傳遞不屬于它的 base64 字母表的字符，crypt 函數(shù)將完全失敗，這正好證實(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.
取一個(gè)假想的鹽1234".這與 base64 完全一致，因?yàn)樗硎?24 位數(shù)據(jù)，即 3 個(gè)字節(jié)，并且不攜帶任何需要丟棄的數(shù)據(jù).這是一個(gè) Len Mod 4 為零的鹽.將任何字符附加到該鹽上，它就變成了一個(gè) 5 個(gè)字符的鹽，并且 Len Mod 4 現(xiàn)在是 1.但是，這個(gè)額外的字符只代表 6 位數(shù)據(jù)，因此不能轉(zhuǎn)換為另一個(gè)完整的字節(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.
因此，對(duì)于任意兩種鹽 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() 用于計(jì)算散列的實(shí)際鹽實(shí)際上是相同的.作為證明，我提供了一些可用于展示這一點(diǎn)的示例 PHP 代碼.鹽以半非隨機(jī)方式不斷旋轉(zhuǎn)(基于當(dāng)前時(shí)間到微秒的漩渦散列的隨機(jī)片段)，以及要散列的數(shù)據(jù)(此處稱為 $種子) 只是當(dāng)前的 Unix-Epoch 時(shí)間.
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
);
}
這會(huì)產(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 使用兩種不同的鹽生成相同的哈希?的文章就介紹到這了，希望我們推薦的答案對(duì)大家有所幫助，也希望大家多多支持html5模板網(wǎng)！