BCRYPT（SHA1（パスワード））の安全性
この質問は、ここの前の質問からの分岐です： ハッシュされたパスワードと同じフィールドにソルトを格納することは安全/賢明ですか？
Webポータルを実行し、パスワードをSHA1ハッシュに格納するとします。代わりにこれをBCRYPTハッシュにどのようにアップグレードしますか？
通常、ユーザーがログオンするのを待ち、パスワードを（ユーザーが入力したプレーンテキストから）BCRYPTにハッシュし直します。ただし、すべてのユーザーがプラットフォームにログオンするまでにしばらく時間がかかる可能性があり、常に戻ってくることのない非アクティブなユーザーが常に存在します。
別の提案（私が最初にTroy Huntから聞いた）は、データベース内の既存のSHA1パスワードをBCRYPTすることでした。実質的にはBCRYPT(SHA1(plaintext_password))になります。このように、システム上のすべてのユーザーは、アクティビティに関係なく、一度にBCRYPTにアップグレードされます。
このように、データベースの違反は、まだログインしておらず、SHA1にまだログインしていないユーザーを公開しません。
質問は：
- Is
BCRYPT(SHA1(plaintext_password))はセキュリティにおいてBCRYPT(plaintext_password)と同等です - そうでない場合-なぜ？そして、ギャップはこのオプションを検討するのに十分妥当ですか？
質問はBCRYPT（SHA1）に焦点を当てていますが、2つのハッシュアルゴリズムに簡単に適用でき、より強いアルゴリズムが最後に適用されます。
まず、これを正しく行う方法を決定し、ユーザーのセキュリティを向上させるために時間を割いていただきありがとうございます！
レガシーハッシュを考慮しながらパスワードストレージを移行するのは 比較的一般的 です。
移行シナリオでは、bcrypt(base64(sha1(password)))は 妥当なバランス になります。 nullの問題 （重要なことを回避します-確かにbase64ステージを省略したくない！）、bcryptを回避しますネイティブの72文字の制限。既存のハッシュと100％互換性があります。
bcrypt(base64(sha1))を使用して既存のすべてのSHA1をハッシュし、すべての新しいパスワードを完全なシーケンスでハッシュします。 （代わりにSHA256を使用することもできますが、これによりコードの複雑さが少し増加し、SHA1またはSHA25が使用されているかどうかを確認します（または両方を試して、どちらかが成功した場合は合格します）。長期的には、SHA256は衝突に対してより耐性があります。なので、より良い選択です）。
ブルートフォースへの耐性については、これはbcryptと同等であるだけでなく、理論的には優れています（実際には、72文字はパスワードの保存に非常に大きいです）彼らは事実上同じです）。
ボーナスアドバイス：
- オフライン攻撃に耐えるのに十分な高さのbcrypt作業係数を必ず使用してください。これは、ユーザーが許容できる最高値である100ミリ秒以上です（おそらく少なくとも作業係数10）。 1秒未満の速度の場合、bcryptは実際の攻撃者にとって、最新の置換scryptおよびArgon2（YMMV）よりも遅い（防御側にとってはより良い）場合があります。
- 作業係数のデフォルト値をシステム全体の設定可能な変数として保存します。これにより、基盤となるハードウェアの速度が速くなる（または分散される）ときに、定期的に値を増やすことができます。
これにより、キースペースが約2に制限されます160、SHA-1は20バイトのダイジェストを出力しますが、それ以外の場合は問題ありません。実際、bcryptの入力制限は72バイトであるため、暗号化によって安全な高速ハッシュを使用して最初にパスワードをハッシュすることは珍しくありません。制限はSHA-1のダイジェストサイズより大きいため、代わりに、より大きなダイジェストでハッシュを使用することをお勧めします。 nullの問題 では、ダイジェストをbase64などの別のエンコーディングに変換する必要があることに注意してください。
SHA-1ハッシュでいっぱいのデータベースが既にある場合は、bcryptで実行しても問題ありません。