bcryptに渡す前にパスワードをハッシュするためにsha256を使用することの長所と短所は何ですか？
私は最近、bcryptがパスワードを72文字に切り捨てるという事実に気づきました。実際のところ、私の直感は、これによってセキュリティ上の大きな問題が発生することはないということです。ただし、これは、bcryptを使用するすべてのソフトウェアライブラリが、同じ72文字で始まる2つの超長いパスワードが同等であるという「バグ」の影響を受ける可能性があることを意味することを理解しています。
Django Webフレームワークの作成者 BCryptSHA256PasswordHasher この問題を解決します。ユーザーのパスワードをbcryptに渡す前に、まずSHA256でハッシュします。
私のチームの何人かの開発者がこのアプローチのメリットについて議論していたので、私は一般のコミュニティから考えを集めたかっただけです。一方で、これはある意味でbcryptに供給される可能性のある値の合計スペースを縮小することによってセキュリティをreduceしませんか？ SHA256は常に32バイトを出力します。これは、通常の場合の72バイト（有効バイト）をはるかに下回ります。一方、最初にパスワードをハッシュしないと、基本的に、72文字のプレフィックスごとに、そのプレフィックスで始まるすべてのパスワードが衝突する不均一に分散されたスペースができます。
私の直感は、72バイトを超える配布の問題は重要ではなく、BCryptSHA256PasswordHasherは本当に役に立ちません。そうは言っても、一般的に言えば、Django）と同じくらい人気があり、広く使用されているフレームワークは、これらのことを真剣に受け止め、その決定の背後に十分な理由があることを認識しています。それが理にかなっているなら、これについての私の内臓には本当に大きな自信があります。
私が間違っている？ bcryptの前にSHA256でパスワードをハッシュすると、理論的にもセキュリティが低下しませんか？配布の問題は、私が思っているよりも深刻ですか？他にまったく考えていないことはありますか？
リンクに記載されているBcryptは72文字に制限されています。
SHA256の出力サイズは32バイトのみで、メッセージ入力は（（2 ^ 64）-1）\ 8またはおおよそ
2305843009213693952バイト（charが8ビットであると想定）
Bcryptは、暗号化する32バイトのパスフレーズを受信しています。SHA256には、400文字のデータストリーム（IEパスワード）を使用できます。
したがって、これでエントロピーを失うことはなく、Bcrypt設計の制限を克服しています（これを制限と呼びたい場合）。
SHA2に関する議論のリンクはサイズです： https://en.wikipedia.org/wiki/SHA-2
Djangoのドキュメント によると、
パスワードは最初のNULLバイト（存在する場合）で切り捨てられ、パスワードの最初の72バイトのみがハッシュされます...残りはすべて無視されます。
彼らはそれがセキュリティ問題ではないことを認めます：
それ自体はセキュリティの問題ではありませんが、bcryptには大きな制限が1つあります（前を参照）。
また、72Cのパスワードの最後は、残りのパスワードほど重要ではないことに注意してください。
さらに、バイト55〜72は、結果のハッシュに完全には混合されません（引用が必要です）。
「パスワードの最後は最初より解読するのが簡単です」と翻訳できます。
これが、最初にaを実行する理由です（これはNULL文字ではなく、72文字未満で55〜72文字ではありません）。
これらの両方の問題を回避するには、多くのアプリケーションが最初にSHA2-256などのメッセージダイジェストを介してパスワードを実行します。 Passlibは、この問題に対処するために、既成のpasslib.hash.bcrypt_sha256-BCrypt + SHA256を提供しています。
これにより、処理するパスワードが長い場合のセキュリティが向上します。衝突の可能性があるため、通常の（A-Za-z0-9とキーボードからの特殊文字）の短いパスワードしかない場合、これはわずかに減少する可能性があります（重要ではありません）。したがって、汎用ライブラリの場合、ハッシュすることは理にかなっています。ユーザーパスワードを管理するラムダWebサイト/アプリケーションの場合、それは役に立たないようです（まったく実行しないよりも、間違って実行する方がリスクが高くなります）。