Positive Technologies 的網(wǎng)絡(luò)安全研究員 Arseniy Sharoglazov 近日在社交平臺分享了一個簡單的實驗并指出，加密的 ZIP 文件可能存在兩個正確的密碼，并且都可以提取出相同的結(jié)果。

“創(chuàng)建 ZIP：7z a http://x.zip/etc/passwd -mem=AES256 -p

使用這個密碼：Nev1r-G0nna-G2ve-Y8u-Up-N5v1r-G1nna-Let-Y4u-D1wn-N8v4r-G5nna-D0sert-You提取它：7z e http://x.zip

使用這個密碼：pkH8a0AqNbHcdw8GrmSpMagic！”

Sharoglazov 制作了一個名為 x.zip 的受密碼保護的 ZIP 文件，選擇的密碼是 1987 年的熱門英文歌曲的雙關(guān)語：

Nev1r-G0nna-G2ve-Y8u-Up-N5v1r-G1nna-Let-Y4u-D1wn-N8v4r-G5nna-D0sert-You

但實驗結(jié)果表明，當(dāng)他使用一個完全不同的密碼（pkH8a0AqNbHcdw8GrmSp）提取 x.zip 時，不會收到任何的報錯信息。

對此，BleepingComputer 使用不同的 ZIP 程序成功地對該實驗進行了復(fù)現(xiàn)。該網(wǎng)站使用了 p7zip（相當(dāng)于 macOS 的 7-Zip）和另一個叫 Keka 的 ZIP 工具，與 Sharoglazov 一樣在創(chuàng)建時采用了較長的密碼，并啟用了 AES-256 加密模式。結(jié)果表明，雖然 ZIP 使用較長的密碼加密，但使用任一密碼都能成功提取了存檔。

一些網(wǎng)友在 Sharoglazov 的動態(tài)下針對該實驗進行了討論，一位 ID 為 Unblvr 的用戶指出，造成這個結(jié)果的原因可能在于：

ZIP 使用 PBKDF2，如果輸入太大，它會 hash 輸入 。該 hash（作為原始字節(jié)）成為實際密碼。嘗試使用 SHA1 對第一個密碼進行 hash，并將十六進制摘要解碼為 ASCII.。. ：）

在啟用 AES-256 模式生成受密碼保護的 ZIP 存檔時 ，如果密碼太長，ZIP 格式會使用 PBKDF2 算法并對用戶提供的密碼進行 hash 處理。在這種情況下，這個新計算的 hash 將會成為文件的實際密碼。研究人員解釋稱，太長是指超過 64 個字節(jié)（字符）。

當(dāng)用戶試圖提取文件，并輸入一個超過 64 字節(jié)的密碼時，用戶的輸入將再次由 ZIP 應(yīng)用程序進行 hash，并與正確的比較密碼（現(xiàn)在本身就是一個 hash）。如果匹配，將可以成功進行文件提取。

示例中使用的替代密碼 pkH8a0AqNbHcdw8GrmSp 實際上是較長密碼 SHA-1 hash 的 ASCII 表示。Nev1r-G0nna-G2ve-。.. 的 SHA-1 checksum = 706b4838613041714e62486364773847726d5370。此校驗和在轉(zhuǎn)換為 ASCII 時產(chǎn)生：pkH8a0AqNbHcdw8GrmSp。

但是值得注意的是，在加密或解密文件時，僅當(dāng)密碼長度大于 64 個字符時才會進行 hash 處理。換句話說，較短的密碼在壓縮或解壓縮 ZIP 的任何階段都不會出現(xiàn)這種情況。這也是為什么在加密階段選擇長的 “Nev1r-G0nna-G2ve-。..” 字符串作為密碼時，ZIP 程序設(shè)置的實際密碼實際上是該字符串的 （SHA1） hash。

如果在解密階段輸入 Nev1r-G0nna-G2ve-。..，它將被 hash 并與之前存儲的密碼（即 SHA1 hash）進行比較。但是，在解密階段輸入較短的 “pkH8a0AqNbHcdw8GrmSp” 密碼將使應(yīng)用程序直接將此值與存儲的密碼（也就是 SHA1 hash）進行比較。

“當(dāng)使用 HMAC 作為其偽隨機函數(shù)時，PBKDF2 有一個有趣的特性。可以輕松地構(gòu)造任意數(shù)量的不同密碼對，每對密碼對都存在沖突。如果提供的密碼長于底層 HMAC hash function 的塊大小，則首先要將密碼 pre-hashed 成一個 digest，然后將該 digest 作為密碼使用。”

不過，同一個 ZIP 有兩個可能的密碼這一事實并不代表存在有安全漏洞；因為生成密碼的 hash 的前提是需要知道原始密碼。