レガシーデータベース上に構築された新しいシステムのセキュリティを強化する

Question

私たちは、塩漬けされたMD5ハッシュとして顧客パスワードを保存した古いレガシーASPアプリケーションを持っています。これを置き換えるために、ASP.NET MVCに新しいアプリケーションを書きました。

パスワードフィールドの保護にノッチを付けて、SHA1ハッシュを使用したいと思います。明らかに、私は顧客に新しいSHA1ハッシュを作成するためにパスワードを更新させることなくこれを行う必要があります。

私の考えは、SHA1を使用して既存のMD5ハッシュをハッシュすることでした。つまり、MD5でハッシュし、SHA1で再度ハッシュする必要があることを意味します。これは、顧客がログオンしたときやパスワードをリセットしたときに繁殖することができます。

誰もこの方法で欠陥を見つけることができますか？私には

はハッシュ戦略を決定するために第2の列を導入ハッシュをサポートしています（以下参照）に列を広げ

Answer 1

SHA1を使用するのではなく、Bcryptなどを使用する必要があります。

しかし、そうでなければあなたの計画は妥当と思われます。幸いなことに、既存のハッシュは簡単に識別できる形式なので、データベースに新しい列を追加したくない場合は、識別子の接頭辞を追加することができます。

md5、md5 + bcryptまたはbcryptを処理できるようにコードを変更することをお勧めします。オンラインログインコードがbcryptにアップグレードされている間、md5からmd5 + bcryptにパスワードをアップグレードするバックグラウンドプロセスを実行できますか？

Answer 2

1. のように思えます。
2. この値に基づいてどのハッシュストラテジが使用されているかを検出するためにログイン（および同様の）およびパスワード変更/リセットルーチンを変更して適用します。値が「推奨されない」ハッシュでハッシュされている場合は、暗黙的にアップグレードしてください（パスワードを確認してからユーザーのプレーンテキストでパスワードを取得するため）
3. 妥当な期間が経過したら、古いパスワードハッシュをアップグレードしていないユーザー

コード化された出力の長さに基づいて、SHA1に比べてストレートMD5とSHA1は32バイトを占めますが、SHA1には40が必要ですが、 "ハッシュストラテジー"には情報（アプリケーションに意味があります。 ）、ハッシュ反復の回数など、ハッシュに対して実行される他の操作についての情報が含まれますが、一般的にはもう少し堅牢です。将来、3番目のハッシュ（Tiger-192など）を導入し、アップグレードプロセスを繰り返すこともできます。

もう1つの列をスペアできない場合は、プレフィックスをサポートするように既存のものを広げて、ハッシュのインジケータを表示します（例： {SHA1}xxxxxxxxxxxxx - 古いハッシュはプレフィックスされず、MD5とみなされます。