セキュリティを損なうことなくライブデータベースのハッシュ方式をアップグレードする方法
外部からアクセスできるイントラネットプロジェクトに取り組んでいます。パスワードは、通常のハッシュおよびソルト方式でSQL Serverデータベースに格納されます。問題は、ハッシュアルゴリズムにあります。
現在はSHA512Cngを使用していますこのアルゴリズムが使用された理由の背後にある決定を見つけることができません。 アップグレードこのハッシュアルゴリズムbcryptを使用するために加えて、ソルトキーを長くしたいと思います。
もちろん、パスワードはハッシュ化されているため、バッチを実行してパスワードをアップグレードすることはできません。
認証方法をライブデータベースの安全性の低いものから安全性の高いものにアップグレードするときに利用可能なパスは何ですか？
もちろん、SHA512Cngメソッドが現在提供しているのと同じくらい安全なデータベースを維持し、アップグレードプロセス中にデータベースを危険にさらすことはありません。
ハッシュをハッシュし、ユーザーがパスワードを正常に認証または更新したときに更新します。このようにして、即時のセキュリティが得られます。これが、取り組みの主要なポイントです。
実装：
すべてのSHAハッシュはbcryptを使用してdbにハッシュするため、bcryptハッシュのみが存在します。ユーザーが認証されるときに、bcrypt（パスワード）を使用して同等かどうかを確認します。失敗した場合は、bcrypt（sha512（password））と比較します。ユーザーが認証に成功したり、パスワードを更新したりするときに、bcryptを使用してパスワードをハッシュします。
主なトレードオフは、2、3行の追加コード（2次ハッシュ比較）を維持する必要があることです。しかし、これは、安全でないハッシュされたパスワードを回避しながら2番目のパスワード列を維持するよりもはるかに優れています。
編集：ああ！ Ramhoundが質問へのコメントで同じアイデアを返信したことに気付く前に投稿しました。彼と同意する。
次のログイン時に、各ユーザーを新しいパスワードハッシュ方式に段階的に切り替えることをお勧めします。その時点で、あなたは彼らのクリアテキストのパスワードを知っているので、bcryptでそれを再ハッシュしてbcryptに切り替えることができます。これにより、「旗の日」やすべてのユーザーに連絡する必要がなくなります。実際、ユーザーには見えません。ユーザーは、新しいパスワードハッシュアルゴリズムに移行していることを知る必要はありません。
さらに詳細に：
データベースに別のフィールドを追加して、パスワードハッシュの計算に使用されたハッシュアルゴリズムの種類を示します。つまり、各ユーザーに関連付けられた2つのフィールドがあります。1つはパスワードハッシュ用で、もう1つはハッシュアルゴリズム（SHA512Cngまたはbcrypt）を示します。最初に、すべてのユーザーのパスワードハッシュアルゴリズムはSHA512Cngに初期化されます。
ユーザーがログインしようとすると、自分のアカウントのパスワードハッシュアルゴリズムを検索し、そのアルゴリズムを使用して提供したパスワードをハッシュし、保存されているハッシュと比較します。一致しない場合、ログインは拒否されます。一致する場合、ログインは受け入れられます。
さらに、ログインが受け入れられ、データベース内のアルゴリズムがSHA512Cngである場合、bcryptを使用してパスワードを再ハッシュし、パスワードハッシュを新しいbcryptハッシュで上書きし、データベース内のアルゴリズムをbcryptに変更します。
これにより、ユーザーがサービスにログインしたときに、新しいパスワードハッシュアルゴリズムに徐々に移行できます。
必要に応じて、数か月が経過した後、まだログインしていないユーザーがいる場合（したがって、パスワードがSHA512Cngでハッシュされている場合）、パスワードをリセットするか、電子メールで送信して、再度ログインするように要求することができます。ただし、多くの場合、これは必要ない場合があります。
追伸または、単にパスワードハッシュを暗号化するというラムハウンドのエレガントなソリューションを使用することもできます。賢い！
一般的な方法は、新旧両方のハッシュ方法が使用される一時的な期間を使用することです。これには、データベースで両方のタイプのハッシュを区別できることが必要です。ハッシュ方式は、ユーザーからの次回のログイン時に古いものから新しいものにアップグレードできます。次の数か月以内にログインできるように、ユーザーをやさしく微調整できます。または、6か月間ログインしていないユーザーのアカウントを無効にすることもできます。詳細については この質問 を参照してください。
移行期間中も、次のことができますチェーンハッシュ：古いハッシュ値を新しいハッシュ値の「パスワード」として使用します。古い関数が無塩のパスワードのハッシュである場合、これは簡単です。古い関数がソルトを使用していた場合は、新しい関数のために新しいソルトと一緒に維持する必要があります。
理想的には、ソルト処理および反復処理されたハッシュ関数を使用し、元のパスワードを必要とせずに追加の反復を追加できるようにします。私の知る限りでは、それをサポートする広範なパスワードハッシュ関数は存在しませんが、差し迫った不可能性はありません（暗号学者はまだやらなければならない仕事があります）。
通常の方法は、ユーザーに連絡して、たとえば翌月中にログインする必要があることをユーザーに通知し、ログインしたら、その時点でハッシュをアップグレードすることです。
この方法では、ユーザーがログインするときにユーザーの古いパスワードのハッシュを確認し、新しいパスワードのハッシュを保存する以外に何もする必要はありません。
必要なのは、アップグレードしたユーザーを追跡し、古いハッシュを削除することだけです。