[解決済み] パスワードハッシュのための非ランダムなソルト
質問
UPDATE: 私は最近
この質問
で知ったのですが、以下の議論全体において、私は(そして他の人もそうだと思いますが)少し混乱していたようです。私がレインボーテーブルと呼んでいるものは、実際にはハッシュテーブルと呼ばれるものです。レインボーテーブルはもっと複雑なもので、実はヘルマンハッシュチェーンの変形なのです。このように、「虹のテーブル」と呼んでいるものは、実は「ハッシュテーブル」なのです。
質問: "です。
レインボー テーブルとは何ですか、そしてどのように使用されるのですか?
"
通常、レインボーテーブル攻撃から保護するために、ハッシュ関数 (パスワード用など) で使用するソルトとして、暗号学的に強力なランダム値を使用することを常にお勧めします。
しかし、ソルトがランダムであることは、実際に暗号学的に必要なのでしょうか?この点については、任意の一意な値 (ユーザーごとに一意な、たとえば userId) で十分ではないでしょうか? それは実際、システム内のすべての (またはほとんどの) パスワードをクラックするために単一の Rainbow Table を使用することを防ぐでしょう...。
しかし、エントロピーの欠如は、本当にハッシュ関数の暗号強度を弱めるのでしょうか?
注:なぜソルトを使うのか、どのように保護するのか(その必要はありません)、単一の定数ハッシュを使うのか(使わないでください)、どのようなハッシュ関数を使うのか、について聞いているのではありません。
塩がエントロピーを必要とするかどうかだけ。
これまでの回答には感謝しますが、私は(少し)あまり精通していない領域に焦点を当てたいと思います。主に暗号解読への影響 - 私は、誰かが暗号数学的な観点からいくつかのインプットを持つ場合、最も感謝します。
また、考慮されていなかった追加のベクトルがある場合、それも素晴らしい意見です(複数システムに関する @Dave Sherohman の指摘を参照)。
さらに、理論、アイデア、ベストプラクティスなどがあれば、証明、攻撃シナリオ、または経験的な証拠のいずれかでこれをバックアップしてください。あるいは、許容可能なトレードオフのための有効な考慮事項でも構いません...。私はこのテーマに関するベスト プラクティス (大文字 B、小文字 P) に精通していますが、これが実際にどのような価値を提供するかを証明したいのです。
しかし、@Dave が言うように、一般的なユーザー名と、あまり一般的でない名前の Rainbow テーブルに行き着くのだと思います。しかし、ユーザー名がグローバルに一意である場合はどうしたらよいでしょうか。私のシステムで一意である必要はありませんが、各ユーザーごとに、例えば電子メールアドレスなど。
また、クラスタリングを防ぐことができます。唯一の問題は、異なるサイトで同じ電子メールとパスワードを持っている可能性があることです。
つまり、暗号解読に戻るわけですが、エントロピーは必要なのか、必要でないのか?(私の現在の考えは、暗号解読の観点からは必要ありませんが、他の実用的な理由からは必要です)。
どのように解決するのですか?
ソルトは従来、ハッシュ化されたパスワードの接頭辞として保存されていました。 これはすでに、パスワード ハッシュへのアクセス権を持つすべての攻撃者に知られていることになります。 ユーザー名をソルトとして使用してもしなくても、その知識には影響しないため、単一システムのセキュリティに影響を与えることはないでしょう。
しかしながら、ユーザー名または他のユーザーが制御する値をソルトとして使用することは、同じパスワードハッシュアルゴリズムを使用する複数のシステム上で同じユーザー名とパスワードを持っているユーザーが、それらのシステムのそれぞれで同じパスワードハッシュを持ってしまうので、クロスシステムセキュリティを低下させるでしょう。 私は、攻撃者として、ターゲットアカウントが他のシステムで使用したことがあることが分かっているパスワードを、そのアカウントを侵害する他の手段を試す前に、まず試してみるので、これは重大な責任とは考えていません。 同一ハッシュは、既知のパスワードが機能することを事前に教えてくれるだけで、実際の攻撃をより容易にすることはありません。 (ただし、アカウントデータベースを素早く比較することで、誰がパスワードを再利用しているか、していないかがわかるので、より優先度の高いターゲットのリストを提供することができます)。
たとえば、どんなサイトにも "Dave" というユーザー アカウントがあり、"admin" や "root" はさらによくある名前です。
これらの欠陥の両方は、ハッシュ化する前にパスワードに 2 つ目のソルト値 (固定で非表示、または標準のソルトのように公開) を追加することで効果的に対処できますが、その時点では、ユーザー名を組み込む代わりに、標準のエントロピー ソルトを使用するだけでもかまいません。
を追加するために編集されました。
多くの人がエントロピーについて、そして塩のエントロピーが重要であるかどうかについて話しています。
塩のエントロピーは重要か?
一般的な考え方は、攻撃者が塩を推測するのが難しくなるように、エントロピーが重要であるというものです。 これは間違っており、実際、まったく関係ありません。 さまざまな人が何度か指摘しているように、ソルトによって影響を受ける攻撃は、パスワード データベースを持つ誰かによってのみ行うことができ、パスワード データベースを持つ誰かが、各アカウントのソルトが何であるかを確認するだけでよいのです。 推測可能かどうかは、些細なことで調べることができるときには重要ではありません。
エントロピーが重要である理由は、ソルト値のクラスタリングを回避するためです。 ソルトがユーザー名に基づくもので、ほとんどのシステムが "root"または "admin"というアカウントを持っていることがわかっている場合、これら 2 つのソルトについて虹色のテーブルを作成し、ほとんどのシステムを解読することが可能です。 一方、ランダムな 16 ビットの塩が使用され、ランダムな値がほぼ均等に分布する場合、すべての 2^16 の可能な塩のための虹のテーブルが必要です。
攻撃者が個々のアカウントのソルトを知ることを防ぐのではなく、潜在的なターゲットのかなりの割合で使用される単一のソルトという大きな目標を与えないようにすることです。
関連
-
[解決済み] なぜパスワードにはStringではなくchar[]が好まれるのですか?
-
[解決済み] 後で平文を取り出すためのユーザーパスワードの保管について、倫理的にどのように取り組むべきでしょうか?
-
[解決済み] PHPでパスワードをハッシュ化するためにbcryptを使用するにはどうすればよいですか?
-
[解決済み] bcryptはどうして塩を内蔵しているのですか?
-
[解決済み】PHPパスワードのハッシュとソルトの安全性について
-
[解決済み】塩の文字列はどこに保存していますか?
-
[解決済み】レインボーテーブル攻撃に対してパスワードソルトはどのように役立つのでしょうか?
-
[解決済み] ベストプラクティス。パスワードのソルティングとペパリング?
-
[解決済み] SHA-1はパスワードの保存に安全か?
-
[解決済み] ハッシュのソルトを隠蔽する必要性
最新
-
nginxです。[emerg] 0.0.0.0:80 への bind() に失敗しました (98: アドレスは既に使用中です)
-
htmlページでギリシャ文字を使うには
-
ピュアhtml+cssでの要素読み込み効果
-
純粋なhtml + cssで五輪を実現するサンプルコード
-
ナビゲーションバー・ドロップダウンメニューのHTML+CSSサンプルコード
-
タイピング効果を実現するピュアhtml+css
-
htmlの選択ボックスのプレースホルダー作成に関する質問
-
html css3 伸縮しない 画像表示効果
-
トップナビゲーションバーメニュー作成用HTML+CSS
-
html+css 実装 サイバーパンク風ボタン
おすすめ
-
[解決済み] 好きな「プログラマー」アニメは?
-
[解決済み] サーバー側に送信する前にパスワードをハッシュ化した方が良いですか?
-
[解決済み] なぜ、すべてをHTTPSにしないのか?
-
[解決済み] Firefoxの同一生成元ポリシーを無効にする
-
[解決済み] ステートレス(セッションレス)・クッキーレス認証を行うには?
-
[解決済み] ポーカーボットを倒す
-
[解決済み] SSLとMan-in-the-Middleの誤解
-
[解決済み] CORSとCSPの違いは何ですか?
-
[解決済み] GETリクエストのクエリパラメータとしてurlにjwtを入れるのは安全ですか?
-
[解決済み] ウェブサイトの管理画面を保護するためのベストプラクティスとは?[クローズド]