時間の経過に伴うハッシュ関数の作業係数の増加
長い間、ハッシュ関数は、データベースリークが発生した場合に個々のパスワードを保護するのに十分な低速の操作を維持するために、作業係数を必要としてきました。 BcryptとPBKDF2は注目すべき例です。
また、セキュリティに関しては「自分自身を転がさない」ことも承知していますが、ハードウェアの増加により、パスワードハッシュ方式の作業要素が時間の経過とともに急速に増加する状況を想像するのは簡単です。データベースの所有者が自分のハードウェアをアップグレードする状況を想像することもできます。そのため、ハードウェアのアップグレード前に使用されていたものより高い作業係数が適切で、パスワードごとの安全性が向上します。
問題は、パスワードを「再ハッシュ」する必要があることです。平文または暗号化されたパスワードをデータベースに保存したくないため、システムはパスワードに再度アクセスして作業要素を変更する方法がないためです。 。これを修正するには、ユーザーがログインするときにこの再ハッシュを実行するだけです。ユーザーがシステムに平文パスワードをすでにログインしている場合は常に、パスワードのハッシュ検証が成功すると、システムは以前に関連付けられた作業要素をチェックできます。パスワードのハッシュ（bcryptで簡単に実行できます）。システムオペレーターが選択した標準の作業係数よりも小さい場合は、平文パスワードが再ハッシュされ、新しい作業係数と新しいソルトで保存されます。以前と同じパスワードが使用されているため、セッションをリセットする必要はありません。異なる作業要素とソルトのみです。
プレーンテキストのパスワードがパスワードの検証中にわずかに長くメモリに存在することと、作業係数の増加が発行されるたびにパスワードの検証に時間がかかることを除けば、このモデルの障害は見つかりません。私が見逃したセキュリティ上の欠陥はありますか？
あなたはそれをかなりうまくまとめているようです。
私が考えることができる唯一の欠点は、システムの非アクティブなユーザーです-彼らは再びログインすることができないか、次回の違反の前にログインする機会がないかもしれない、つまり保存されたパスワードがより多いので、以前の作業要因を持ち続けるでしょう攻撃に対して脆弱です。格納されたデータ内で仕事の要素が見えるため、攻撃者はどの設定が古い設定を使用しているかを知ることができます（ただし、各パスワード内の相対的なエントロピーはわかりません）。
これを防ぐには、たとえば6か月間ログインしていないアカウントを定期的に無効にし、同時にパスワードを空白にします。将来ログインする必要がある場合は、 パスワードを忘れた場合の機能 を使用して、新しいパスワードを設定し、新しい作業要素で保存することができます。
重要な点は、データベースにパスワードハッシュがあるため、パスワードを再ハッシュする必要がないことです。それらを（正確には、salt ect。で）N回ハッシュしたとしましょう。作業係数を2倍にするには、データベースでハッシュをさらにN回ハッシュし直します。そして、これと同じリハッシュを将来のログインに適用します。参照 https://crypto.stackexchange.com/questions/3003/do-i-have-to-recompute-all-hashes-if-i-change-the-work-factor-in-bcrypt =および BCryptまたはPBKDF2がすでに計算されており、元のパスワードがない場合、BCryptまたはPBKDF2のコストを増やすことは可能ですか？ 詳細については、.