すでにハッシュされたパスワードにbcryptを適用することには、暗号化の欠点がありますか
私は最初に this on stackoverflow と尋ねましたが、牽引力の欠如とそこでのユーザーからの推奨のため、ここでも尋ねました。
クライアントアプリケーションがパスワードをバックエンドサーバーに送信して、ユーザーが正しいパスワードを入力したことを、保存されているパスワードのバリエーションと比較して検証できるシナリオを想像してみてください。
トランスポートメカニズムはHTTPSで、サーバーはユーザーエージェントにHSTSとHPKPを提供し、SSLラボテストでA +をスコアリングするサーバーは強力な暗号を優先します。それでもなお、元のユーザーが提供したパスワードをユーザーエージェントからサーバーに送信しないようにしたい場合があります。代わりに、クライアントでSHA-256を何度か実行した後で、ハッシュを送信する可能性があります。
サーバー側では、パスワードの保存に多数のラウンドでbcryptを使用しています。
暗号化の観点から、プレーンテキストパスワードを直接使用するのではなく、すでにsha-256でハッシュされた値に対してbcryptを実行することに不利な点はありますか？ハッシュを使用するときの入力テキストの固定長の性質は、どういうわけかアルゴリズムの強みを弱めますか。
値の計算、保存、送信、比較に必要なメモリ、CPU、ストレージ要件、実時間などのパフォーマンスについては質問していません。格納された値の完全なリストが公開された場合に、bcryptを適用する前にハッシュを適用するとbcryptの強度が弱まるかどうかに純粋に関心があります。
私は投稿を読みました this （これは興味深いし、便利だと思います）が、クライアント側でハッシュするのが良いアイデアであるかどうかを具体的に尋ねているわけではありません。この知識で武装した攻撃者が、格納されたすべての値が、可能な限り狭い範囲の文字（SHA-256）で構成される入力の固定セット長の派生物であることを知っている場合、bcryptでパスワードストレージシステムをどうにか弱体化します。
まあ、理論的には入力としてSHA256出力を明示的に使用すると、可能な入力の量が制限されますが、SHA256出力の数が多いため、これは無視できるほどの要素になります。ハッシュ出力はほとんど疑似ランダムであるため、これを知っていても（今日の私たちが知る限り）実際の利点はありません。すべての可能なSHA256出力と2の間に大きな違いはないはずです256 関数に供給されるランダムな文字列。出力からパターンを実際に導出することはできません（可能であれば、ハッシュ関数は不適切です）。暗号化の観点からは、大きな影響はありません。
シナリオに関するコメント、またはクライアント側のハッシュ法がプレーンテキストの送信よりも改善されない理由：
クライアント側のハッシュを使用すると、攻撃者がクリアテキストのパスワードを取得することを防ぎます[〜＃〜] if [〜＃〜]（非常に高いセキュリティ標準について説明したように、巨大な場合） SOMEWHEREの接続を妥協します。ただし、パスワードを送信する前にハッシュすると、提供されたパスワードがハッシュまたは「topSecretK3y」であるかどうかがサーバーで考慮されないため、事実上、新しいパスワードになります。
攻撃者がこのハッシュを取得すると、被害者になりすますことができるため、その値は元のパスワードと同じくらい高くなります。
PS：唯一の「欠点」は、攻撃者が他のWebサイトのユーザー名/パスワードを使用できないことです。そのため、他のWebサイトでの「パスワード再利用攻撃」を少なくとも防ぐことができます。