web-dev-qa-db-ja.com

PBKDF2のパスワード履歴

シナリオ：

  • 以前の15個のパスワードは使用できません
  • 1秒の実行時間を目標とする反復でPBKDF2を使用する

このシナリオでは、ユーザーが新しいパスワードを作成する場合、サーバーはそのパスワードを以前に使用されたパスワードから最大15個のソルトと組み合わせる必要があります。これは、最悪のシナリオでは、ユーザーのパスワード変更に約16秒かかり、サーバーに大きな負担がかかることを意味します。

このストレスを軽減するにはどうすればよいですか？ PBKDF2の実行時間を0.1秒のようなものに減らしますか？以前に使用したパスワードリストを減らしますか？

password-policypbkdf2
1
Travis Watson

「前の15」の要件はどこから来ていますか？それが実際にセキュリティを大幅に改善する可能性は低いようです-私の最初のステップは、それが法律、規制、業界、または監査の要件から来ていない場合、それを減らすことです。

  • オンライン攻撃をしている攻撃者はまったく気づきません
  • 現在のパスワードだけに対してオフライン攻撃を行っているPWデータベースを使用している攻撃者は、攻撃中は気にしません
  • 攻撃者の部分に関するより複雑なパターン通知分析はここに入るには複雑すぎますが、football1、次にfootball10、football100などを使用するユーザーを想像してください。football100000000が試されなくても、パスワードがいくつかある場合、パターンは明らかです。パスワード推測の非常に遅い段階まで（もしあれば、何十万もの反復を使用しなければならないことを考えると）

また、一度にN個の異なるPBKDF2値を試すことは、複数のコアを使用できることを意味することに注意してください。つまり、15個のPBKDF2がそれぞれ1秒で実行される場合、10個のコアがある場合、これには2秒ほどかかる可能性があります（最初の1秒で10、2秒で5）。ただし、同じ（またはわずかに多い）CPU時間を使用することになります。注意してください。

PBKDF2の実行時間の短縮減少セキュリティが大幅に低下します。これは、攻撃者が同じ割合で実行する必要のある作業が少なくなるためです。 1秒のCPU時間をターゲットにする余裕がある場合（おそらく、ログインの頻度がかなり低い場合、または非常に多くのサーバーファームの場合）、それを維持してください。これにより、攻撃者のワークロードが減少するのと同じレベルで劇的に増加します。私はそれをお勧めしません。

ログインごとに1秒のPBKDF2作業をターゲットにしている場合、ほぼ同時にログインする15人のユーザーは、他の15個の固有のソルトPBKDF2操作とまったく同じワークロードです-予想されるピークの下で現在のターゲット時間を確保できることを確認してください次の2〜3年間の負荷。また、ユーザーはどのくらいの頻度でパスワードを変更しますか？

もう1つの選択肢：

  • 毎回ユーザーのソルトを変更しないでください。
    • これはnot素晴らしいアイデアですが、実行でき、パフォーマンスの問題を解決します。ただし、完全なパスワードリストを持つオフラインの攻撃者は、試行ごとに16倍の確率でパスワードを推測できます。
    • パスワードを2〜6回変更するたびにソルトを変更するだけで、妥協点が見つかります。パスワードを非常に頻繁に変更する場合は、それほど悪くはありません。

P.S. P @ $$ w0rd1、P @ $$ w0rd2、P @ $$ w0rd3、P @ $$ w0rd ...、P @ $$ w0rd999を使用してユーザーを獲得することをご存知ですか？

2
Anti-weakpasswords

これはどうですか？パスワードを変更するときは、古いパスワードを要求し（とにかくそうしますか？）、古いパスワードが一致するかどうかをテストするだけでなく、1回の反復で古いパスワードを再ハッシュします。もはや有効ではないので、クラックするのがどれほど簡単かについてはあまり気にしません（クラックしても攻撃者の助けにはならないため）。そして、高速ハッシュバージョンを履歴に保存します。

古いパスワードを取得できない場合があるため（管理者によって変更された場合など）、古いパスワードフィールドにマーカーを入れて、ハッシュ方法を示すことができます。そうすれば、システムは両方のバリエーションと互換性があります。

0
tylerl

Travisが言っていないのは、そもそも古いパスワードを使用することが全体的な目的であったということです。つまり、監査にはそれが必要かもしれませんが、なぜそれが必要なのか誰も言っていません。それはおそらく悪い考えです。一般に、セキュリティを向上させることはなく、パフォーマンスの問題は別として、正しく実行されない場合、セキュリティが大幅に低下するリスクがあります低下。適切に行われるよりも不適切に行われる可能性がはるかに高くなります。

アカウントの「所有の連鎖」を確保することが目的である場合、パフォーマンスの低下をほとんど伴わずにこれを行うことができる他の方法があります。

簡単な例を次に示します。疑似乱数ジェネレーターがそもそも優れている場合、任意の数のソルトのXORは、単一のソルトとまったく同じようにランダムである必要があります。暗号による違いはありません。何でも。

したがって、そのユーザーのすべてのソルト（現在のソルトを含む）、XORそれらをすべてまとめて、現在のパスワードを生成または認証するときに実際のソルトとして使用できます。

これにより、明確で必要な履歴が確立されます。セキュリティが低下することはありません。XORは非常に高速であり、PBKDF2への呼び出しは1回だけです。

0
Lonny Eachus