長密碼和 Bcrypt
我需要儲存 Web 應用程序的密碼，並且正在尋找 Bcrypt 尋找可能的解決方案。經過一些研究，似乎只有前 72 個字節會影響最終的雜湊輸出。雖然應用程序可以將輸入限制為 72 個字元，但這會傷害使用生成非常長密碼的密碼管理器的使用者。
雖然眾所周知，這
hash1(hash2(x))只會增加衝突，但似乎沒有太多關於 using 的含義的資訊bcrypt(hash1(x))，如this answer所示。第一個想法
如果密碼
p是p > 72字節，SHA512$$ 64 bytes $$密碼，然後 Bcrypt 雜湊。 可能的缺點：
- 散列雜湊
- Bcrypt 的輸入只和散列函式的輸出一樣大（64 字節）
第二個想法
如果密碼
p是p > 72字節，請使用（虛擬碼）計算雜湊：bcrypt(p[0:8] + sha512(p))這個 Bcrypt 是密碼的前 8 個字節（即 72 - 64，其中 64 是 SHA512 雜湊的字節）與 SHA512 的串聯
$$ 64 bytes $$整個密碼的摘要。這樣，Bcrypt 函式對整個 72 個字節進行雜湊處理，而不是像普通的舊 SHA512 那樣只有64 個字節$$ 64 bytes $$雜湊。 可能的優點：
- 完整的 72 個字節是 Bcrypt 的
- Bcrypt 不只是一個雜湊；這可能會使如果在 SHA512 中發現衝突$$ 64 bytes $$雜湊，還有剩餘的 8 個字節的熵來破解密碼
可能的缺點：
- 仍然涉及部分散列雜湊
我的印像是第二種想法是最好和最安全的方法，但我不確定這是否會降低長度 > 72 字節的密碼的安全性。我在問選擇這種方法是否有任何明顯（或不明顯）的安全隱患。
大多數情況下，生成 16 個字元密碼的密碼管理器就足夠了。使用 100 字節密碼的使用者通常過於偏執，因為實際的安全優勢被不便所抵消。因此，將密碼限制為 72 個字元，同時在理論上減少可能的密碼數量，仍然是非常合理的。
也就是說，如果散列相關，散列散列是一個壞主意。
sha512(sha512(password))比 更容易發生碰撞sha512(password)。但是，bcrypt（用河豚建構）與 sha512 有很大不同，這並不適用（更不用說 bcrypt 是鹽漬的）。雖然您仍在將使用者密碼從 72+ 字節減少到 64 字節，但使用者密碼的預期熵是小於 512 位的數量級。可以安全地假設sha512(password)，雖然在技術上比 短password，但與原始密碼相比具有很大的熵。您的第二個想法似乎是重用密碼的一部分，所以我認為安全性沒有太大提高。來自的熵
p[0:8]已經足夠用 sha512 展開了。