ソルトを使用する方が安全なのはなぜですか？
ユーザーのパスワードのハッシュを保存する。データベースでは、人間のパスワードは辞書攻撃に対して脆弱であるため、安全ではありません。これは塩の使用によって緩和されると誰もが提案しますが、塩は非敏感であると考えられており、保護する必要はありません。
攻撃者が塩を持っている場合、辞書攻撃は以前よりもどのように難しくなりますか？塩にアクセスできないため、効果的に塩の有用性が失われていませんか？
Saltは、パスワードを1つだけ入力した唯一の攻撃者からユーザーを保護しません。 1つのパスワードを解読したい攻撃者は、hash(salt + guess)ではなくhash(guess)を計算します（パスワードスキームが hash(salt+password) の場合）。
ソルトは、攻撃者が多くのパスワードを解読したい場合に役立ちます。これは通常のケースです。攻撃者がサイトを攻撃していて、そのサイトのアカウント、任意のアカウントに侵入したい場合があります。ソルトがなければ、攻撃者の作業のほとんどはすべてのアカウントに使用できるため、攻撃者はすべてのアカウントに対して一度に各試行をテストできます。 正しく選択されたソルト の場合（つまり、同じソルトを持つ2つのアカウントがない場合）、攻撃者はハッシュされたパスワードごとに最初からやり直す必要があります。
さらに、ある意味で、すべてのパスワード解読の試みは、すべてのアカウントのパスワードを一度に解読しようとしています。これは、ハッシュを事前に計算できるためです。必要なのは、誰かがハッシュのテーブル（より効率的には Rainbow table ）を生成することであり、その最初の作業は、同じものを使用する任意のアカウントデータベースでそれを使用できる複数の攻撃者に分散できます。パスワードハッシュアルゴリズム。繰り返しになりますが、saltはこれらの事前計算を役に立たなくします。
ブルートフォースパスワード攻撃は、次のように要約できます。
- レインボーテーブルを作成するなど、攻撃者が有用と考える事前計算を行います（これは、一般的なパスワードへのハッシュをマッピングするテーブルを表す効率的な方法です）。
- 攻撃者が侵入しようとしているnアカウントのすべてに対して、およびpのすべてに対してパスワードは、攻撃者が辞書に含めることを推測し、
hash(guess[i]) = hashed_password[j]かどうかをテストします。
素朴なアプローチでは、2番目のステップにはn×pハッシュ計算が必要ですすべてのアカウントに対してすべての推測を試みます。ただし、最初のステップですべての可能なハッシュがすでに計算されている場合、2番目のステップではハッシュ計算はまったく必要なく、各hashed_passwordは事前計算されたデータベースにあるため、攻撃にはnテーブルルックアップのみが必要です（これは高速化することもできますが、すでにnxp計算が遅い¹=nテーブル検索）。
各パスワードに異なるソルトが含まれている場合、役立つためには、事前計算にすべての可能なソルト値のエントリを含める必要があります。 ソルトが十分に大きい場合、事前計算は実行不可能です。 事前計算でソルトが考慮されない場合、暗号化ハッシュ関数があるため、2番目のステップを高速化することは役に立ちません。その入力を混合します。UIOQWHHXpasswordのハッシュを知っていても、NUIASZNApasswordのハッシュを計算するのに役立ちません。単一のアカウントを攻撃する場合でも、攻撃者はすべての推測を試行するためにpハッシュ計算を実行する必要があります。すでに十分な単一のテーブル検索の改善です。攻撃者が事前に計算した辞書を持っている場合。
¹ パスワードはSHA-1などのハッシュとして保存しないでください。ただし、 bcryptまたはscryptまたはPBKDF2 などの低速なハッシュ関数を使用します。
データベースに保存されたパスワードの各レベルのセキュリティについて説明します。これは、saltの重要性を明確にするのに役立ちます。
レベル1：データベースに平文で保存されたパスワード。
これは単なる純粋な愚かさです。しかし、大企業ではデータベースが危険にさらされることがあり、驚いたことに、すべてのパスワードがクリアな状態で保存されています。残念だ！
レベル2：ハッシュアルゴリズムを使用して保存されたパスワード。
これは、セキュリティを強化するためのステップです。攻撃者がハッシュ化されたパスワードを取得しても、この資格情報を使用してサービスにログインすることはできません。彼は最初にパスワードを「ハッシュ解除」する必要がありますRainbow Table を使用するか、または brute forcing itを使用します。つまり、攻撃者にはもう少し作業が必要ですが、元のパスワードを取得することは依然として可能です。
レベル：ソルトを含むハッシュアルゴリズムを使用して保存されたパスワード。
これは興味深いものになります。 レベル2で見たように、ハッシュされたパスワードにアクセスできる攻撃者は、ブルートフォースまたはRainbowテーブルを使用できます。元のパスワードにソルトを追加すると、レインボーテーブルはまったく役に立たなくなりますになるため、ソルトは考慮されません。レインボーテーブルを使用して元の文字列を取得することも可能ですが、レインボーテーブルにはパスワード+塩が存在することになります。ソルトは一般に非常に長いため、string（40+）のハッシュ値を持つことはほとんど不可能です。残された唯一の解決策は、総当たりです。
レベル4：saltとpeperのハッシュアルゴリズムを使用して保存されたパスワード。
これは非常に興味深いです（実際の回答は既に興味深いので、私が回答を投稿するのはこのためです）。
BCrypt、SCrypt、またはPBKDF2のようなハッシュアルゴリズムを使用することをお勧めします。これは、これまでのところ簡単に解読されておらず、ハッキングが非常に遅く、解読に時間がかかるため、パスワードの完全なデータベースです。
塩コショウの違いは、その位置です。ソルトは通常データベースに格納されますが、コショウはコードにあります。これは奇妙に思えるかもしれませんが、元の考えでは、データベースは危険にさらされる可能性がありますが、コードは侵害されず、攻撃者に塩と無用なハッシュパスワードのリストが残されます。さらに、ハッシュされたパスワードがさらに複雑になり、Rainbowテーブルは完全に役に立たなくなりますになります（ソルトを使用してもまだ少し便利だと仮定した場合）。
データベースのみが危険にさらされている場合、攻撃者は1つの値（元のパスワード）ではなく2つの値（元のパスワードと唐辛子）を探しているため、ブルートフォースは役に立たないであっても。
あなたのハッシュが無塩の場合、私はハッシュに相当する辞書全体を生成してデータベースに保存できます（特別な種類のレインボーテーブルと呼ばれ、多数のハッシュに対してより効率的です）。基本的に、1つの巨大なメモリとCPU時間の最適化。また、同じハッシュを持つ2人のユーザーが同じパスワードを使用していることがわかります。
ソルトはすべてのユーザーのパスワードハッシュを一意にします。正しく行うと、他のサイトで同じパスワードを使用している場合でも（珍しいことではありませんが）一意になる可能性があるため、実際にはWordを使用する必要があります。ソルトを適用し、それをハッシュし、辞書の次のエントリに対して繰り返します。
無塩ハッシュは、ルックアップ攻撃に対して脆弱です。ハッシュの平文を検索するために使用できる何百万ものパスワードハッシュ（主にMD5とSHA1）を含む無料で利用可能なデータベースがあります。これらは、標準のリレーショナルデータベース、またはRainbowテーブルなどの特殊なデータベース形式に基づいている場合があります。
だから、ここに例があります：7c6a61c68ef8b9b6b061b28c348bc1ed7921cb53（無塩）2d67062d67b4d0eaca31a768e901d04982de7352（ "RxB6aE"プレフィックスでソルト化）
最初のハッシュをすばやく検索すると、プレーンテキストが「passw0rd」であることがわかります。ただし、後者はほとんど見つかりません。攻撃者がソルトを知らない場合、辞書やブルートフォース攻撃が困難になります。
データベースでパスワードを保護する場合は、bcryptなどを使用する必要があります。ハッシュアルゴリズムの多数の反復を使用して、各計算を遅くします。そのため、ブルートフォース攻撃、辞書攻撃、レインボーテーブルの構築は、非常に実行不可能です。