3

レインボーテーブルの導入以来、データベースに保存されたパスワードにハッシュパスワード（例：MD5）のみを使用することは、最も安全な方法ではありません。

人々が塩漬けのハッシュについて話すときは、常にこのようにhash(password . salt)、あるいはそれを使用してhash(hash(password) . salt)ください。

ソルトを使用する理由がわかりません。また、ソルトを保存するためにパスワードごとにエントリを追加しますか？なぜhash(hash(password))、あるいは単に使用しないのhash(hash(hash(password)))ですか？

塩を入れる方が安全ですか？それとももっと複雑な感覚ですか？

4

8 に答える 8

23

hash（pwd）のディクショナリに基づいてレインボーテーブルをhash（pwd）の2倍の時間で作成でき（パフォーマンスは主にディスク書き込みに関するものであるため、さらに少なくなります）、それ以上になることはありません。ソルトを使用すると、テーブルに必要なサイズが実用的でない量まで大幅に拡大します。

また（さらに重要なことですが）、ユーザーは同じパスワードを持っていることがよくあります。ユーザーごとに個別のソルトがないと、1人のユーザーのパスワードを破った場合、同じパスワードを持つ他のすべてのユーザーを破ったことになります。

于 2010-12-19T13:44:51.497 に答える
12

簡単にするために、誰もがパスワードとして数字を使用していると想像してみましょう。

全員がパスワードとして8桁を使用する場合、それは1億の可能性です。システムを破壊しようとしている場合は、それらすべての可能性をハッシュする必要があります。「ハッシュのハッシュのハッシュ」がある場合でも、それらの1億の可能性をハッシュする必要があります-少し複雑な方法で。

ここで、4桁のソルトもあるとしましょう。現在、1億の可能性の代わりに1,000,000,000,000があります...潜在的な攻撃者に、3倍の作業ではなく、10,000倍の作業を与えました。

基本的に、ソルトは、すべての人のパスワードを人為的に長くして、辞書攻撃が機能しなければならないスペースを拡張する方法と考えてください。

編集：明確にするために、ソルトがプレーンテキストでも提供されていることを考えると、1つのハッシュを攻撃しようとする可能性は1億回しかありません。ただし、あるパスワードでこれらの可能性を試した後、攻撃者は別のパスワードを攻撃するための有用な情報を入手できないことを意味します。ソルトがないと、攻撃者は1億の可能性のある辞書を作成し、ハッシュのみを指定してデータベース内のすべてのパスワードを知ることができます。言い換えれば、塩はかさばりを防ぐのに役立ちます攻撃。また、辞書を事前に生成できないことも意味します。単一のパスワードを効果的に攻撃するには、事前にソルトを知っている必要があります。ソルトがなければ、ハッシュ自体にアクセスする前に、考えられるすべてのパスワードのハッシュを計算できます。

于 2010-12-19T13:43:32.197 に答える
7

ソルトを使用しない場合、攻撃者は単一のレインボーテーブルを作成して、データベース内のすべてのパスワードを攻撃することができます。レインボーテーブルは、説明したとおりにハッシュを連鎖させることで機能するため、複数回ハッシュしてもソルトなしでは保護​​されませんhash(hash(password))。

ユーザーごとにランダムなソルトを追加すると、攻撃者は同じテーブルを再利用して2つのパスワードを解読できないため、ユーザーの作業は非常に困難になります。追加の利点として、ソルトが使用されている場合、同じパスワードを持つ2人のユーザーが異なる値にハッシュします。

ハッシュを繰り返すというあなたの考えはまだ良いですが、あなたも塩が必要です。これを行う場合：

function hashPassword(password, salt) {
    result = hash(salt . password)
    for (i = 0; i < 1000; i++) {
        result = hash(salt . result)
    }
    return result
}

次に、攻撃者の作業を1000倍難しくし、正当なユーザーへの影響はごくわずかです。攻撃者は、1台のローエンドコンピューターで毎秒数百万の候補パスワードをテストできることに注意してください。ハッシュ関数は高速になるように設計されています。この1000回の反復ループは、実行可能な攻撃を100年以上かかる攻撃に変える可能性があります。コンピューターが18か月で高速化したら、反復回数を2000に変更するだけです。

ソルト、ハッシュアルゴリズム、反復回数は秘密にする必要はなく、計算されたハッシュと一緒にデータベースに保存できます。固定の反復回数とハッシュアルゴリズムを選択できますが、ソルトはユーザーごとにランダムに生成する必要があります。

于 2010-12-19T13:50:02.650 に答える
4

ハッシュを繰り返すこととソルトを使用することの両方で、パスワードハッシュのセキュリティが向上します。しかし、それらは完全に異なる攻撃から保護します。

ハッシュを繰り返すと、ブルートフォース攻撃に必要な作業が増えます。ただし、提案するように単純な反復を使用するのではなく、PBKDF2などのそのために設計されたアルゴリズムを使用する必要があります。

ソルトは事前に計算されたテーブルから保護するため、Webサイトやユーザーごとに異なる必要があります。

于 2010-12-19T13:56:59.257 に答える
0

塩のポイントは、辞書攻撃を無意味にすることです。これで、ハッシュをいくら再ハッシュしても、同じ入力で常に同じ出力ハッシュが生成されるため、そのための辞書を作成できます。したがって、複数のハッシュはブルートフォース攻撃をより困難にする可能性がありますが、辞書攻撃には何もしません。

于 2010-12-19T13:41:32.640 に答える
0

二重にハッシュされたパスワード用のRainbowテーブルを作成することを妨げるものは何もありません。

于 2010-12-19T13:43:17.817 に答える
0

ログインするユーザーのパスワードをハッシュするために、同等の方法を使用します。ソルト（ランダム値）がセッションで生成され、クライアントに送信されます。ユーザーはパスワードを入力します。パスワードはソルトでハッシュされて返送されます。これにより、サーバーから送信される値が毎回異なるようになり、中間者攻撃での侵入が困難になります。

于 2010-12-19T14:14:41.727 に答える
-1

ソルトは、サイトまたはユーザー固有の値です。つまり、攻撃者はパスワードを取得するために、データベースへのアクセスとソルトの両方を知っている必要があります。

さらに、攻撃者はさらに1回テーブルを生成し、それを複数のサイトに対して使用する可能性があります。ただし、ソルトを使用すると、攻撃者はサイトごとに1つのテーブルを生成するか、ユーザーごとに1つのテーブルを生成する必要があります（攻撃を遅くします）。

サイト固有のソルトは、Webサイトのセキュリティにほとんど影響を与えません。コメントで述べたように、サイト固有のソルトとユーザー固有のソルトを組み合わせることで、サイト固有のソルトよりもセキュリティを大幅に向上させることができます。

数年前、私はここstackoverflowで、あなたに役立つかもしれないパスワードストレージについて質問しました。PHPパスワードの安全なハッシュとソルトを参照してください。

于 2010-12-19T13:43:18.303 に答える