ユーザー指定の反復回数
私はPHP認証および登録システムで、標準のsalt + password = 'auth hash'に従い、最初のクエリのルックアップフィールドとしてプレーンテキスト/暗号化されていないユーザー名を使用しています。この質問について、私もグローバルペッパーを使用していると仮定しましょう（終了する前に追加する可能性が高いので、すでにそれを行っているとしましょう）。
何か面白いコンセプトだと思いました。私は彼らが「セキュリティに関しては車輪の再発明をしないでください」と言っていることを理解していますが、私はPBKDF2に対して「ユーザー指定」の反復回数を許可することを検討していました。
さて、ユーザーが反復回数を制御できるという意味ではなく、実行時にXとYの間の乱数が生成され、その値がプレーンテキストでデータベースの個別のフィールドとして格納されます。塩を保存するのと同じ方法です。アルゴリズムはすでに非常に安全でありながら実装が簡単であると見なされていることは理解していますが、「レイヤー」を追加すると、攻撃者が攻撃するのがさらに難しくなると思います。
簡単にするために（そして食品の使用を継続するために）、ランダム反復カウントを「ソース」と呼びましょう。例として;
- PepperはすでにDBにあり、変数に取得されます
- ユーザーはユーザー名とパスワードで登録します
- 塩が生成されます
- ソースが生成され、16000〜32000回の反復である必要があります（理論値）
- ハッシュはsalt + password + petper + sauceから生成されます
- ユーザー名、ハッシュ、ソルト、ソースはDBに保存されます
'sauce'はプレーンテキストとして保存されるため、アルゴリズム自体はデータベースに保存されているものに基づいて適応します（saltの場合と同様）。さらに重要な点として、XとYの間の数値の選択は一般に非常に高速です。
繰り返しになりますが、攻撃者が32000（例番号）の反復を経て妥当な時間内にソルトアンドペッパーを持っているSHA512ハッシュ512ビット長の出力キーを壊す可能性があることを心配していません。それに対するレインボーテーブル。 「ディフェンダー」側のオーバーヘッドをほとんど追加せずに、比較的簡単に設計をさらに拡張できるが、攻撃者側にオーバーヘッドを追加し、攻撃者を完全に阻止する可能性があり、適応する必要がないという見通しにもっと興味があります。ハッシュアルゴリズム自体。
環境が処理できる範囲内で独自の最小および最大反復回数を設定するため、システムの相対的なセキュリティを大幅に制御でき、エンドユーザーが独自の値を指定することはできません（パフォーマンス上の理由から、彼らはあなたの余分なステップを完全に無効にする記憶に残る何かを選択する可能性が高いという理由で、そして素敵なUXを作るために）。セキュリティが最も重要な環境では、これらの余分な小さなステップを邪魔することは、防御側の利益に役立つでしょう。
この余分なレベルがあると、攻撃者がジャンプするためのさらに別のフープが提供されませんか？考え？
ソースは余分なフープではありません。攻撃者は、ソースを事前に知っていても何のメリットもありません。塩は彼がとにかく有用な事前計算をするのを防ぎます。
最適な反復回数は、利用可能なコンピューティング能力と一般的な攻撃者が利用できるコンピューティング能力との間の妥協点から決定されます。確かに、それを正確に定量化することは困難ですが、それにもかかわらず、ランダム化は結果の値を最適でなくするだけです。
攻撃者が組織に足場を築きたいと考えており、どのアカウントに違反したかをあまり気にしない場合、ソースが最も低いアカウントが最初に落ちる可能性があります（ただし、パスワードの複雑さがより影響を及ぼします）。ランダム化は、処理時間の増加による相応の補償なしに、最も弱いリンクを弱くするため、このシナリオで役立つ以上に痛いです。
あなたのランダムなソースは、私がほんの少しでも、非常に複雑です。複雑さはセキュリティの敵です。誤って間違える可能性があるもう1つのことです（たとえば、最小限のソースが低すぎるなど）。
結論として、プロセッサがより強力になるにつれて時々変更する、固定の反復回数をお勧めします。
シナリオでは：
- 私はあなたのパスワードを持っています、ハッシュされています
- 正しい方法で塩を使用しているので、事前に計算されたレインボーテーブルは使用できません
- すでに持っている塩、コショウ、ソースを使ってブルートフォースする必要があります...
さて、まず第一に、調味料はあなたから与えられるので、私は自分のサラダを持参する必要があります:)
第二に、あなたは塩のようにそれを持っているので、それはthat秘密ではないので、私は反復回数を持っています。
しかし、それがなくても、それらすべての反復を計算する必要があります。 16,000から32,000になることがわかっている場合は、16、000日後に結果をテストします。あなたの計画では、32,000まで繰り返す代わりに、おそらく私は幸運で、その前に結果を得ることができます。テストするのに、新しい反復をすべて計算するよりも多くの計算能力が必要かどうかわからないので、試してみる価値があるかもしれません...
そして最後に、 レインボーテーブル は事前に計算された値を最適化する方法であり、単なるルックアップテーブルではありません。
システムのパフォーマンスと、これが承認プロセスに追加する予想される計算オーバーヘッドを考慮して、反復回数を許容できる限り高くする必要があります。ユーザーごとに調整可能になることは絶対にありません。さらに、この値をどこかに保持する必要があります。つまり、秘密とは見なされないため、これ以上速度を落としたり、攻撃者になる可能性のある人を阻止したりすることはありません。攻撃者になる可能性がある可能性を提供するだけです。個々のハッシュをブルートフォースするという彼のタスクを、あなたが生きることができる最大の反復回数よりも速く完了します。
ああ、なぜあなたの反復回数を秘密にしておくことができないのですか？まあ、簡単です。その値を保護するための非常に独創的なスキームを使用した場合でも、後でそれを使用することになり、反復値が異なると、計算のオーバーヘッドも異なります。これは、攻撃者がいわゆる タイミング攻撃 で確認できるものです。 =。攻撃者は、ライブシステムを使用して、各アカウントに使用される反復回数を比較的高い精度で判断する可能性があります。