動的に生成された非ランダムソルトの暗号セキュリティ
したがって、セキュリティに関しては、良いと思われるアイデアはあるものの、だれもやっていないように思える場合、私は明白なものやその他の重要なものを見落としていると思い込もうとします。これはそのようなケースの1つです...
この質問のコンテキストは、私が取り組んでいる認証システムです。私は過去に同様のシステムを実装したことがあり、一般的に「塩とハッシュ」のことを頭に持っていますが、私は決して暗号化セキュリティの専門家ではありません。
ユーザーレコードに16ランダムバイトのソルト用のストレージを定義しているときに、誰かが私のユーザーデータを盗んだり、その他の方法でアクセスしたりした場合に、攻撃対象を減らす方法があるのではないかと思いました。私は次の仮定に基づいて動作しています：
- ハッカーが私のユーザーデータを盗んだ場合、ハッカーはユーザーのパスワードのソルト付き+（繰り返し）ハッシュ表現とソルト値自体にアクセスできます。
- ハッカーがそのパスワードのプレーンテキストの値を特定したい場合、その前に強引な労力がかかります。
- しかし、ソルトが与えられると、ブルートフォース攻撃のサーチスペースは大幅に減少します。*
*ポイント3が正しいかどうかは100％わかりませんが、ブルートフォースアルゴリズムでプリハッシュ値が<8-or-so-bytes-of-password> + <16-bytes-from-stolen-salt>（またはパスワードとソルト値の同様の組み合わせ）の場合、アルゴリズム的に重要な量だけ検索スペースを削減しました。
<この質問の長さについての必須の質問中の謝罪>
上記が私の現在の考えですが、私が検討しているソリューションは基本的に、ユーザーに関する既知の定数値を使用して、ハッシュステップ中に使用するソルトを動的に生成することです。
ソルト値は、ブルートフォースディスカバリを必要とする点まで推測できない限り、暗号的に「何でも」である必要はないので、提供されたユーザー名とパスワード（たとえば、いくつかのSHA-2の良さと独自の暗号を適用し、それをハッシュステップで使用しますか？
もちろん、誰かがコードを盗んだとしても、「秘密の」塩の生成は無意味です。 私が達成しようとしている唯一の追加のセキュリティは、ハッカーが私の両方のデータを盗ませるようにすることですand上記の削減された検索スペースの利便性が必要な場合は私のコードポイント3で
私は私の質問と推論を適切に（そしてtoo冗長に）記述していないことを願っています。私が答えたいと思っている具体的な質問は、これがユーザーのパスワードを保存および比較する暗号的に（またはその他の方法で）安全な手段であるかどうかです。
- ハッシュ値の生成に使用されるソルトへのアクセスは、実際のパスワードの発見に対するブルートフォース攻撃を実質的に助けますか？
- もしそうなら、それはデータ自体に加えて私のコードを盗む必要があることでハッカーを悩ませることは理にかなっていますか？
- 塩を動的に生成する一般的なアプローチ（再現性があり、ランダムではないが推測できない手段を使用）は不適切です。
あなたは塩の役割についていくぶん誤解されています。 「」ではありません「攻撃者が攻撃できない」という意味です。推測できないように意図されている場合、それは機密データの一部であり、「塩」ではなく「鍵」と呼びます。
ソルトは、攻撃者が攻撃するときに 規模の経済 を作成することを防ぐために、パスワード導出プロセスを一意にするためにありますseveralパスワード。攻撃者が3つのパスワードを推測しようとする場合、攻撃者はパスワードを攻撃する場合の3倍のコストがかかるはずです。 「規模の経済」の大きな脂肪の例の1つは、一般的なパスワードの事前計算されたハッシュの大きなテーブル（またはその邪悪な子孫である Rainbow table ）です。単に巨大です）。ソルトが存在する場合、oneハッシュ関数はありませんが、ソルト値ごとに1つ;または、別の言い方をすると、事前計算されたテーブルは特定のソルト（計算中に使用されるもの）に固有であり、そのソルトを使用しないパスワードを攻撃する価値はありません。
もちろん、攻撃者がハッシュされたパスワードのコピーを取得できても、対応するソルトを取得できない場合、彼の仕事は非常に困難になります。しかし、これはもっともらしいシナリオではありません。塩を攻撃者の手の届かないところに置くことができるストレージ領域がある場合、ハッシュされたパスワードもそこに保存しなかったのはなぜですか？したがって、セキュリティ分析では、塩が攻撃者に知られていると想定しています。それらの有用性はそれらの一意性に由来します：同じまたは異なるシステムで、同じまたは異なる時間に2つの異なるハッシュされたパスワードが同じソルト値を持つことはありません（同じユーザーの2つの連続したパスワードでさえありません：パスワードを変更すると、塩も変えます）。
ソルト値を再利用する可能性がごくわずかである限り、「ダイナミックジェネレーター」を使用しても、適切な方法でソルトを生成して保存できます。これは非常に正確ですため、公開されている必要があり、攻撃者が「推測できない」必要はありません-推測できないものは必要です 重砲 。
「ペッパー」と呼ばれることもある、わずかに関連する概念があります。asecret keyisalsoをハッシュプロセスに挿入します（ この前の質問 を参照）。そのキーはシステム全体で共有されます。少なくとも一部の構成では（たとえば、SQLデータベースではなくプライベート構成ファイルにそれを保持するなど）、ハッシュされたパスワードのデータベース全体よりも一意のキーの方が機密を保持しやすいと考えられます。 「コショウ」の概念は、より複雑な管理（バックアップして失わない、またはフロントエンドサーバー間で共有しないこと）を意味し、攻撃者がユーザーデータベースをダンプできるフリンジシナリオでのみ価値がありますない完全なホストシステム。いずれにせよ、「pepper」はソルトが提供する一意性プロパティを認識しないため、ペッパーはソルトをreplaceしてはいけません-おそらく補数それ。
これはコメントには少し時間がかかりました。
塩は確かに彼らに出発点を与えます。
ただし、特定のパスワードを知ることの価値は、ほとんどの場合、ユーザーテーブルから取り消すことができるパスワードの総数にのみ関連しているため、これは一般的には問題となる問題です。言い換えると、彼らが文字通り何年ものコンピュータ時間を費やして、10個のパスワードを引き出さなければならない場合、そのデータは事実上価値がありません。
ユーザーが複数のサービスで同じパスワードを再利用する傾向があるため、ユーザー名とパスワードをサイトから削除することには価値があります。ハッカーがパスワードを取得したサイトと同じサイトにユーザーとしてログインすることは、明らかに重要ではありません。パスワードを取得できた場合、必要な他のデータも取得できる可能性が高いためです。
これらのユーザー名とパスワードを販売するとき、それらのキーはFacebookアカウントや銀行サイトなどの他のロックを開く可能性があるため、価値があります。彼らが価値を持っている他の唯一の状況は、Sony alaの公開フォーラムにユーザー名/パスワードを投稿することによって公にあなたを恥ずかしく思うことです。
したがって、パスワードごとにランダムなソルトを使用している場合は、価値のあるものをばかばかしいほどに得るのにかかる時間はすでに増加しています。さらに、妥当な時間内にこれらすべてのパスワードを解読するために必要なリソースを持つ人々は、政府機関である可能性が最も高いです...これはまったく別の問題です。
これが私の投票につながります。解決する別の問題を見つけてください。