有沒有辦法安全地使用密碼長度超過 72 字節的 bcrypt？
據我了解，BCrypt 將密碼截斷為 72 個字節。如果密碼長於 72 字節，有什麼方法可以安全地使用 bcrypt 儲存該密碼而不影響它？或者這是不正確的，我們應該讓 bcrypt 截斷它？
我問的原因是我已經看到了一些實現，他們首先對密碼進行 SHA-256，然後將其輸入 BCrypt（例如PassLib bcrypt_sha256）。然而，SHA-256 輸出是一個 32 字節的摘要。如果 SHA-256 之前的原始密碼長於 32 個字節，那麼不會通過將其縮短為 32 個字節來使用 SHA-256 對 bcrypt 進行散列處理？
如果 SHA-256 是這種情況，SHA-512 會是 64 字節更安全的選擇嗎？
我在Wikipedia和SE Cryptography等地方看到他們說 56 字節是最大密碼字節長度。如果不是 72 字節，那麼對於 bcrypt 密碼來說，什麼密碼字節長度是最佳的？
如果是這種情況，那麼對於小於最佳字節長度的密碼，將它們散列到更長的字節長度是否更好？
介紹
BCrypt 是基於密碼的KDF（遠不是最先進的，但比 PBKDF2 更好，因為 BCrypt 需要相當大的 RAM，這大大增加了硬體加速密碼搜尋的成本）。
Bcrypt 基於塊密碼 Blowfish，密碼的初始處理讓人想起Blowfish 的密鑰預處理。Bruce Schneier對新的可變長度密鑰、64 位分組密碼 (Blowfish) 的描述（在1993 年 12 月舉行的第一次 FSE 會議的會議記錄中）定義 Blowfish 的密鑰為 4 到 56 字節（32 到 448 位） , 以這個理由為最大值：
密鑰大小的 448 限制確保每個子密鑰的每一位都依賴於密鑰的每一位。（請注意，每一點 $ P_{15} $ , $ P_{16} $ , $ P_{17} $ ， 和 $ P_{18} $ 不會影響密文的每一位，並且任何 S-box 條目只有一個 $ .06 $ 影響任何單個密文塊的機率。）
為 Blowfish 使用超過 56 字節的密鑰違背了它的定義和設計原理：超過 72 nd的密鑰字節沒有任何影響，而之前的幾個字節的傳播可能會少一些（儘管沒有上面引用所暗示的那麼糟糕）。一些 Blowfish 實現仍然接受具有任何正字節數的鍵。
Bcrypt，如 Niels Provos 和 David Mazières 的A Future-Adaptable Password Scheme（在 Usenix 1999 的會議記錄中）中所定義的，接受 1 到 72 個字節的密鑰；即使使用最低成本參數，所有關鍵字節都有足夠的時間來達到完全擴散。超過第 72 個字節（如果有）沒有任何影響。密碼到密鑰的映射通過以下方式“定義”：
將使用者選擇的密碼作為密鑰
眾所周知，實現方式千差萬別。只有ASCII？一些 8 位程式碼頁擴展？用 0x3F 字節替換 gremlins？Little-endian 或 Big-endian UTF16 還是 UTF32？UTF8，帶或不帶 BOM？長度字節，零終止？你的猜測！
如果密碼可以超過 72 字節怎麼辦？
如果有正式要求不可能顯示等效密碼，或者密碼中的每個字元都很重要，或者使用 UTF32 編碼的密碼（因此只有 18 個字元），那麼將密碼/密碼片語截斷為72 字節。
如果密碼中的所有字元都成為雜湊的輸入，並且雜湊輸出中的所有字節都成為密鑰（我可以想像一個實現，其中散列中最左邊的 0x00 之外的字節（如果有的話）將被忽略；這將是非常糟糕的，因為 256 個密碼中的一個可以被其散列的第一個字節等於 0x00 的任何密碼替換）。
雜湊值在計算上的抗衝突性應明顯優於不可能展示等效密碼的要求強度（因此輸出為 $ h $ 位與 $ h $ 明顯高於 $ 2k $ 如果針對 $ k $ -位安全級別，並且從防碰撞的角度來看是完整的；從理論上講，沒有 MD5，甚至沒有 SHA-1）。所有其他屬性的強度（通過蠻力搜尋密碼的最小預期成本、第一和第二原像抵抗、對長度擴展的抵抗，以及更普遍地與隨機預言的計算不可區分）顯然來自 Bcrypt 的安全性。
如果存在熵 $ e $ 輸入密碼中的位，以及 $ h $ 位與隨機預言無法區分，預計大約有 $ \max(e,h) $ 提供給 Bcrypt 的密鑰中的熵位，幾乎正好是什麼時候 $ e\ll h $ 或者 $ e\gg h $ ，並且在小於約 $ 0.83 $ 最壞情況下的位 $ e=h $ （見此）。
因此，SHA-256（32 字節）對於人類輸入的任何密碼/密碼片語在實踐中都非常好（或者更重要的是，記住了）；SHA-512（64 字節）不會造成傷害。如果一開始就有足夠的熵，就會留下足夠的熵。