なぜ塩は辞書攻撃を「不可能」にするのですか?


85

更新:ソルトとは何か、レインボーテーブルとは何か、辞書攻撃とは何か、ソルトの目的は何かを尋ねていないことに注意してください。私は質問しています:ユーザーのソルトとハッシュを知っているなら、彼らのパスワードを計算するのはとても簡単ではありませんか?

私はプロセスを理解しており、いくつかのプロジェクトで自分で実装しています。

s =  random salt
storedPassword = sha1(password + s)

保存するデータベース:

username | hashed_password | salt

私が見たソルティングのすべての実装は、パスワードの最後または最初にソルトを追加します。

hashed_Password = sha1(s + password )
hashed_Password = sha1(password + s)

したがって、彼の塩の価値があるハッカーからの辞書攻撃(ha ha)は、上記の一般的な組み合わせで保存されている塩に対して各キーワードを実行するだけです。

確かに、上記の実装は、根本的な問題を実際に解決することなく、ハッカーに別のステップを追加するだけですか?この問題を回避するための代替手段はありますか、それとも私は問題を誤解していますか?

私が考えることができる唯一のことは、ソルトとパスワードをランダムなパターンで組み合わせたり、他のユーザーフィールドをハッシュプロセスに追加したりする秘密のブレンドアルゴリズムを使用することです。実りあることを証明するための辞書攻撃のためにそれらを。(コメントで指摘されているように、更新します。ハッカーがすべての情報にアクセスできると想定するのが最善であるため、これはおそらく最善ではありません)。

ハッカーがパスワードとハッシュのリストを使用してユーザーデータベースをハッキングすることを提案する方法の例を挙げましょう。

ハッキングされたデータベースのデータ:

RawPassword (not stored)  |  Hashed   |     Salt
--------------------------------------------------------
letmein                       WEFLS...       WEFOJFOFO...

一般的なパスワード辞書:

   Common Password
   --------------
   letmein
   12345
   ...

ユーザーレコードごとに、共通のパスワードをループしてハッシュします。

for each user in hacked_DB

    salt = users_salt
    hashed_pw = users_hashed_password

    for each common_password

        testhash = sha1(common_password + salt)
        if testhash = hashed_pw then
           //Match!  Users password = common_password
           //Lets visit the webpage and login now.
        end if

    next

next

これが私の主張をよりよく説明してくれることを願っています。

10,000個の一般的なパスワードと10,000個のユーザーレコードがある場合、できるだけ多くのユーザーパスワードを検出するには、1億個のハッシュを計算する必要があります。数時間かかる場合がありますが、実際には問題ではありません。

クラッキング理論に関する最新情報

私たちは破損したウェブホストであり、SHA1ハッシュとソルトのデータベースにアクセスし、それらをブレンドするためのアルゴリズムを持っていると想定します。データベースには10,000のユーザーレコードがあります。

このサイトは、GPUを使用して1秒あたり2,300,000,000のSHA1ハッシュを計算できると主張しています。(実際の状況ではおそらく遅くなりますが、今のところはその引用された図を使用します)。

(((95 ^ 4)/ 2300000000)/ 2)* 10000 = 177秒

最大長が4文字で、計算速度(可変)で除算し、2で除算した(パスワードを検出するための平均時間が平均して順列の50%を必要とすると仮定)、95個の印刷可能なASCII文字の全範囲が10,000の場合ユーザーは、長さが4以下のすべてのユーザーのパスワードを計算するのに177秒かかります。

リアリズムのために少し調整してみましょう。

(((36 ^ 7)/ 1000000000)/ 2)* 10000 = 2日

大文字と小文字を区別せず、パスワードの長さが7文字未満で、英数字のみを使用すると、10,000ユーザーレコードを解決するのに4日かかります。また、オーバーヘッドと非理想的な状況を反映するために、アルゴリズムの速度を半分にしました。

これは線形ブルートフォース攻撃であることを認識することが重要です。すべての計算は互いに独立しているため、複数のシステムで解決するのに最適なタスクです。(つまり、実行時間の半分になる、異なるエンドからの攻撃を実行する2台のコンピューターを簡単にセットアップできます)。

このタスクをより計算コストの高いものにするために、パスワードを1,000回再帰的にハッシュする場合を考えます。

(((36 ^ 7)/ 1 000 000 000)/ 2)* 1000秒= 10.8839117時間

これは、最大7文字の英数字を表し、1人のユーザーの引用符で囲まれた数値から実行速度が半分未満です。

1,000回の再帰的なハッシュは、包括的攻撃を効果的にブロックしますが、ユーザーデータに対する標的型攻撃は依然として脆弱です。


12
ソルトの要点は、ハッシュされたパスワードを見て、複数のユーザーが同じハッシュ(したがって同じパスワード)を持っていることを確認できないようにすることです。ソルトなしで、ハッシュアルゴリズムを使用して、可能なすべてのハッシュを生成し、そのハッシュを強引に検索することができます。アルゴリズムは決して変更されないため、攻撃者が予測できるようになるため、ソルト処理はそれをはるかに困難にします。
BeRecursive 2010

25
クラッカーはナメクジのようなもので、塩が皮膚の粘液を乾燥させて殺すからです。
TED 2010

6
@TED:私は塩味のクラッカーが好きです。塩漬けのナメクジ、それほど多くはありません。
FrustratedWithFormsDesigner

3
@ Tom-攻撃例では。ソルトがない場合、攻撃者は「一般的なパスワードごとに、パスワードをハッシュします。これは1人以上のユーザーと一致しますか?はい、私は彼らのパスワードを持っています」-攻撃者はすべてのパスワードを「並行して」攻撃できます。 、追加費用なしで。
damien_The_Unbeliever 2010

3
@ TomGullen-全体像は半分しかありません。ソルトがなければ、攻撃者は「アップデート2」で示した方法を使用しません。彼は単にテーブルを検索し、O(1)またはO(log n)時間でパスワードを取得します(nは候補パスワードの数です)。はそれを防ぎ、あなたが示すO(n)アプローチを彼に使用させるものです。別の手法(キー強化)により、ループ内の各試行に1秒かかる可能性があります。つまり、これらのテストの実行には3かかります...パスワードが1万個しかない場合は、パスワードをゼロにする可能性があります。時間。
エリクソン2010

回答:


31

はい、sha1(salt | password)に必要なのはわずか3日です。そのため、優れたパスワードストレージアルゴリズムは1000回の反復ハッシュを使用します。8年かかるでしょう。


3
+1、最も簡潔で、これまでのところ、これが選択肢であることに気づいていませんでした。
トムGullen

どうやらあなたはあなたのシステムでハッシュベンチマークを行ったことがないようです。1秒あたり何百万ものsha1計算を実行できます。1,000ラウンドは、攻撃者にとって無意味です。また、sha1は壊れたハッシュ関数であるため、-1です。
ルーク2011

どうやら私は質問からの名前と番号を使用しています。トピックや明快さなどについて聞いたことがあれば...ああ、それはルークです。気にしないで。
ブレイズ

1
@ Rook、1,000ラウンドは、ブルートフォースに1,000倍の時間がかかることを意味します。私には良い機能のようです。
トムガレン2011年

攻撃者がパスワードを推測できる場合、これはログインでも同じですか(または何かが私に逃げましたか?笑)
khaled_webdev 2013年

62

辞書攻撃を止めることはできません。

パスワードファイルのコピーを取得した誰かがレインボーテーブルを使用してハッシュからパスワードが何であるかを把握するのを阻止します。

ただし、最終的にはブルートフォース攻撃を受ける可能性があります。その部分への答えは、ユーザーに辞書の単語をパスワードとして使用しないように強制することです(たとえば、少なくとも1つの数字または特殊文字の最小要件)。

更新

これについては前に説明したはずですが、一部の(ほとんどの?)パスワードシステムは、パスワードごとに異なるソルトを使用し、パスワード自体と一緒に保存されている可能性があります。これにより、1つのレインボーテーブルが役に立たなくなります。これがUNIX暗号化ライブラリの仕組みであり、最新のUNIXライクなOSは、このライブラリを新しいハッシュアルゴリズムで拡張しています。

私は、SHA-256とSHA-512のサポートがGNUcryptの新しいバージョンで追加されたことを知っています。


17
+1 Saltは、事前に計算されたハッシュのリスト(レインボーテーブル)が役に立たないようにします。攻撃者は最初からやり直す必要があります。
イアンボイド2010

2
PHPでは、md5またはsha1よりも優れた暗号化のためにmcryptまたはbcryptライブラリを使用できます。md5またはsha1で立ち往生している場合は、「ストレッチ」する必要があります。ここでは、データベースに保存されているものに到達する前に、パスワードを1000回ハッシュします。これにより、エントロピーは同じに保たれますが、ハッシュを計算する時間が長くなります。
マルフィスト2010

2
@トムガレン、あなたはどんな記事を読んでいますか?自称専門家または科学雑誌の査読記事?
マルフィスト2010

7
そして、「安全な」システムの書き方についてブログやヘルプの投稿をしているのは、平均的なJoe開発者です。セキュリティはあなたが側で拾うことができるものではありません、それは広範な知識を必要とします。不公平ですか?多分。安全ですか?程度に。セキュリティの専門家がいるのには理由があります。しかし、繰り返しになりますが、すべてがフォートノックスほど安全である必要はありません。ここでの最善のポリシーは、それらの専門家によって設計された構築済みのシステムを使用し、ニーズに合わせてシステムを変更することです。
マルフィスト2010

3
@Michael:ソルトが長い場合、レインボーテーブルに表示するには、可能なすべてのソルト値を事前に計算する必要があります。重要なのは、すべてのパスワードに同じソルトを保持するのではなく、パスワードごとにランダムに選択し、保存されているハッシュソルトパスワードの横にあるデータベースに保存することです。したがって、ハッカーは、可能性のある大きな値のソルトごとにレインボーテーブルにエントリを必要とし、テーブルが大きすぎて実行できないようにします。これがポイントです。
Colin DeClue 2010

31

より正確には、辞書攻撃、つまり網羅的なリスト内のすべての単語が試行される攻撃は、「不可能」ではありませんが、ません実用的ませんソルトの各ビットは、必要なストレージと計算の量を2倍にします。

これは、ソルトが秘密であるかどうかに関係なく、レインボーテーブルを含む攻撃のような事前に計算された辞書攻撃とは異なります。

例:64ビットソルト(つまり8バイト)では、辞書攻撃で264の追加のパスワードの組み合わせをチェックする必要があります。200,000語を含む辞書を使用すると、作成する必要があります

200,000 * 2 64 = 3.69 * 10 24

最悪の場合のテスト-塩なしの200,000テストの代わりに。

ソルトを使用することの追加の利点は、攻撃者が自分の辞書からパスワードハッシュを事前に計算できないことです。時間やスペースがかかりすぎるだけです。

更新

あなたのアップデートは、攻撃者がすでに塩を知っている(またはそれを盗んだ)ことを前提としています。もちろん、これは別の状況です。それでも、攻撃者が事前に計算されたレインボーテーブルを使用することはできません。ここで非常に重要なのは、ハッシュ関数の速度です。攻撃を非現実的にするには、ハッシュ関数を遅くする必要があります。MD5またはSHAは高速になるように設計されているため、ここでは適切な候補ではありません。ハッシュアルゴリズムのより適切な候補は、Blowfishまたはそのバリエーションです。

アップデート2

一般的にパスワードハッシュを保護することについての良い読み物(元の質問をはるかに超えていますが、それでも興味深いです):

レインボーテーブルで十分:安全なパスワードスキームについて知っておくべきこと

記事の結果:bcrypt(Blowfishに基づく)またはEksblowfishで作成されたソルトハッシュを使用すると、構成可能なセットアップ時間を使用してハッシュを遅くすることができます。


4
@Tom Gullen-合理的な強力なパスワードポリシーがあっても、すべてのパスワードが同じように使用される可能性は低いため、数億または数十億の候補の辞書がヒットする可能性があります(人々はRNGではなくニーモニックを使用してパスワードを選択するため) 。そのサイズの辞書がある塩が使用されていない場合は商品のシステム上precomputable。ソルトが使用されている場合、攻撃者は毎回ハッシュを再計算する必要があり、ハッシュの十分な反復が実行されると、攻撃者の攻撃速度は1秒あたり数回の試行に遅くなる可能性があります。
エリクソン2010

3
-1私から:秘密にされることは完全に塩のポイントではありません。とにかくパスワードをチェックするためにアクセス可能である必要があるため、パスワードを秘密にしようとすると、実際に成功するのではなく、複雑さが増してシステムが脆弱になる可能性があります。
Michael Borgwardt 2010

2
@ 0xA3:繰り返しますが、攻撃者に知られていないことは重要ではありません。マシンは何らかの方法でアクセスする必要があるため、マシンに侵入した攻撃者もアクセスできます。攻撃者が塩を知らないシナリオは、赤ニシンです。
Michael Borgwardt 2010

1
リンクされた記事がレインボーテーブルを誤って説明していることは言及する価値があると思います。彼が説明しているのは、単純な辞書の添付です。レインボーテーブルは実際にはかなり異なります(そしてやや複雑です)。レインボーテーブルが実際にどのように機能するかについては、かなり適切な説明があります:kestas.kuliukas.com/RainbowTables
Jerry Coffin

3
-「もちろん、塩は秘密にしておく必要があります」の場合は-1。攻撃者がパスワードハッシュにアクセスできる場合、攻撃者はあなたのソルトも取得します。必要なのはユーザーごとのソルトであり、「隠す」ソルトの隠蔽によるセキュリティではありません。
スネマーチ2010

17

ディクショナリは、値がキーによってインデックス付けされる構造です。事前に計算された辞書攻撃の場合、各キーはハッシュであり、対応する値はハッシュになるパスワードです。事前に計算された辞書が手元にあると、攻撃者はログインに必要なハッシュを生成するパスワードを「即座に」検索できます。

ソルトを使用すると、辞書を保存するために必要なスペースが急速に増大します…非常に急速に、パスワード辞書を事前に計算しようとしてもすぐに無意味になります。

最高の塩は、暗号化乱数ジェネレーターからランダムに選択されます。8バイトは実用的なサイズであり、16バイトを超えると目的がありません。


Saltは、「攻撃者の仕事をより苛立たせる」だけではありません。事前に計算された辞書の使用という、あらゆる種類の攻撃を排除します。

パスワードを完全に保護するには、もう1つの要素が必要です。それは、「キー強化」です。SHA-1の1ラウンドでは不十分です。安全なパスワードハッシュアルゴリズムは、計算が非常に遅くなるはずです。

多くの人が、結果をハッシュ関数に何千回もフィードバックする鍵導出関数であるPBKDF2を使用しています。「bcrypt」アルゴリズムも同様で、低速の反復鍵導出を使用します。

ハッシュ操作が非常に遅い場合、事前に計算されたテーブルが攻撃者にとってますます望ましいものになります。しかし、適切な塩はそのアプローチを打ち負かします。


コメント

以下は私が質問に対してしたコメントです。


ソルトがなければ、攻撃者は「アップデート2」で示されている方法を使用しません。彼は、事前に計算されたテーブルを検索し、O(1)またはO(log n)時間でパスワードを取得するだけです(nは候補パスワードの数です)。ソルトはそれを防ぎ、「アップデート2」に示されているO(n)アプローチを使用するように彼に強制します。

O(n)攻撃に還元されたら、各試行にかかる時間を考慮する必要があります。キー強化により、ループ内の各試行に1秒かかる可能性があります。つまり、1万人のユーザーで1万人のパスワードをテストするのに必要な時間は3日から3年に延長されます…そして、1万人のパスワードだけで、ゼロをクラックする可能性がありますその時のパスワード。

攻撃者がPHPではなく最速のツールを使用することを考慮する必要があるため、100回ではなく数千回の反復がキー強化の適切なパラメーターになります。単一のパスワードのハッシュを計算するのに、ほんの一瞬かかるはずです。

キー強化は、PKCS#5の標準キー派生アルゴリズムPBKDF1およびPBKDF2の一部であり、優れたパスワード難読化アルゴリズムを作成します(「派生キー」は「ハッシュ」です)。

StackOverflowの多くのユーザーは、レインボーテーブルの危険性に関するJeff Atwoodの投稿への回答であるため、この記事を参照しいます。これは私のお気に入りの記事ではありませんが、これらの概念について詳しく説明しています。


もちろん、攻撃者はソルト、ハッシュ、ユーザー名などすべてを持っていると想定します。攻撃者が、myprettypony.comファンサイトにユーザーテーブルをダンプした破損したホスティング会社の従業員であると想定します。彼は振り返って、ポニーファンがcitibank.comアカウントで同じパスワードを使用しているかどうかを確認するため、これらのパスワードを回復しようとしています。

適切に設計されたパスワードスキームでは、この男がパスワードを回復することは不可能です。


1
トムは「辞書攻撃」とは、事前に計算されたハッシュ平文テーブルではなく、既知の弱いパスワード(つまり、人間の言語の辞書から直接)を試すことを指していると思います。これは、「辞書」を読んだときに最初に思い浮かぶことでもあります。このコンテキスト。
Michael Borgwardt 2010

@Michael Borgwardt:同意します、@ ericksonは事前に計算された辞書攻撃を指します。
Dirk Vollmar 2010

1
Saltは、事前に計算された辞書攻撃を阻止します。キー強化は辞書攻撃を阻止します。安全なパスワード認証を行うには、両方を一緒に使用する必要があります。
エリクソン2010

はい、普通の英語のテーブルを意味します。この質問は、ハッカーが各ユーザーアカウントのハッシュの可能なすべての組み合わせを処理するのを防ぐ方法の問題に取り組むことを目的としています
Tom Gullen 2010

7

塩漬けのポイントは、攻撃者の努力の償却を防ぐことです。

ソルトなしで、事前に計算されたハッシュパスワードエントリの単一のテーブル(たとえば、すべての英数字の5文字列のMD5、オンラインで簡単に見つけることができます)は、世界中のすべてのデータベースのすべてのユーザーで使用できます。

サイト固有のソルトを使用すると、攻撃者は自分でテーブルを計算し、サイトのすべてのユーザーでそれを使用できるようにする必要があります。

ユーザーごとのソルトを使用すると、攻撃者はこの作業をすべてのユーザーに個別に費やす必要があります。

もちろん、これは辞書から直接本当に弱いパスワードを保護するのにあまり効果がありませんが、この償却から適度に強いパスワードを保護します。


1
短く正確な答え-ソルトなしまたはサイト全体のソルトありで追加する価値があります。同じパスワードを持つユーザーを簡単に見つけることができ、ブルートフォース攻撃を行うだけで済みます。ユーザーごとのソルトでは、それを行うことはできません。
スネマーチ2010

6

また、もう1つの重要な点として、USER固有のソルトを使用すると、同じパスワードを持つ2人のユーザーが検出されなくなります。ハッシュは一致します。そのため、多くの場合、ハッシュはハッシュ(ソルト+ユーザー名+パスワード)です。

ハッシュを秘密にしておこうとすると、攻撃者もハッシュを確認できません。

編集-上記のコメントで要点が述べられていることに気づきました。


1
ユーザーごとのソルトを指定するように編集する必要があります。サイト全体のソルトを使用しているサイトでも、同一のパスワードを検出できます。
スネマーチ2010

@ snemarch-はい-この重要な区別に感謝します!
ドミニクウェーバー

5

レインボーテーブル攻撃を防ぐためにソルトが実装されています。レインボーテーブルは、事前に計算されたハッシュのリストであり、ハッシュをそのフレーズに変換するのがはるかに簡単になります。最新のハッシュアルゴリズムがない限り、ソルティングはパスワードを解読する最新の防止策としては効果的ではないことを理解する必要があります。

したがって、このアルゴリズムで発見された最近のエクスプロイトを利用してSHA1を使用しているとしましょう。また、1,000,000ハッシュ/秒で実行されているコンピューターがあるとします。 、衝突を見つけるのに530万年かかります。ので、そうですphp 300秒で動作することができます、大きなウープ、実際には問題ではありません。私たちが塩漬けにする理由は、誰かがわざわざすべての一般的な辞書フレーズを生成した場合(2 ^ 160人、2007年のエクスプロイトへようこそ)です。

これが実際のデータベースで、テストと管理の目的で2人のユーザーを使用しています。

RegistrationTime        UserName        UserPass    
1280185359.365591       briang      a50b63e927b3aebfc20cd783e0fc5321b0e5e8b5
1281546174.065087       test        5872548f2abfef8cb729cac14bc979462798d023

実際、ソルティングスキームはsha1(登録時間+ユーザー名)です。どうぞ、私のパスワードを教えてください。これらは本番環境での実際のパスワードです。そこに座って、phpで単語リストをハッシュすることもできます。ワイルドになります。

私は頭がおかしいわけではありません。これが安全であることを知っています。楽しみのために、テストのパスワードはtestです。 sha1(sha1(1281546174.065087 + test) + test) = 5872548f2abfef8cb729cac14bc979462798d023

このユーザーだけの27662aee8eee1cb5ab4917b09bdba31d091ab732ために、レインボーテーブル全体を生成する必要があります。つまり、実際には、単一のレインボーテーブルによってすべてのパスワードが危険にさらされることはありません。ハッカーは、テスト用に27662aee8eee1cb5ab4917b09bdba31d091ab732用にレインボーテーブル全体を生成し、briang用にf3f7735311217529f2e020468004a2aa5b3dee7fを生成する必要があります。すべてのハッシュについて、530万年を振り返ってください。2 ^ 80のハッシュ(20ヨタバイトをはるかに超える)だけを格納するサイズを考えてみてください。そうなることはありません。

ハッシュをデコードできないものにする手段としてソルティングを混同しないでください。これは、レインボーテーブルがすべてのユーザーパスワードを変換するのを防ぐ手段です。このレベルのテクノロジーでは不可能です。


私はレインボーテーブルが何であるかを理解していますが、あなたは私の質問の要点を見逃しています。ソルトアルゴリズム、ハッシュ化されたパスワード、およびソルトを提供してくれた場合は、おそらく数分以内にパスワードが何であるかを教えてくれるでしょう。
トムガレン2010

あなたの口があるところにあなたのお金を入れますか?
シークレット2010

確かに、あなたはあなたの例のパスワードが何であるかを私に教えてくれました、ソルト、ハッシュされたパスワード、そしてソルト+パスワード(非再帰的)をどのように組み合わせるか、そしてパスワード<= 5小文字の英数字(空白なし/特別な文字)このボックスに何が入っているかをお知らせします。あなたが提案するように私にお金をかけたいのなら、私に知らせてください。数分の私のコメントはおそらくひどい過小評価ですが、数時間以内にそうです。
トムガレン2010

1
実際には数秒かもしれません。GPUを使用して「2300M /秒のSHA1ハッシュ/秒」として計算するgolubev.com/hashgpu.htmを参照してください。1〜6文字の範囲の95個のASCII文字の全範囲を使用すると、6分未満で解読できます。小文字の英数字のみの場合、長さが最大8文字<25分。10,000のユーザーレコードのデータベースを使用すると、4文字の完全なASCIIパスワードすべてを200秒未満で見つけることができます((((95 ^ 4)/ 2300000000)/ 2)* 10000)。(引用されたよりもオーバーヘッドが大きく、引用されたGPU速度はおそらく理想的な状況です)。
トムガレン2010

はい、ソルティングは、そのパスワードをブルートフォース攻撃できることを妨げるものではありません。ユーザーが約10文字のパスワードを持っている場合、((10 ^ 5)*(94 ^ 10))= 10 ^ 24を生成するのが難しくなります。これは、ハッシュなしの10 ^ 19よりもはるかに困難です。繰り返しになりますが、1つのパスワードを破ることを難しくするのではなく、前処理されたレインボーテーブルですべてのパスワードを破ることを実行不可能にすることです。(そしてここで私の数学をチェックしてください、しかし私はみんなのパスワードのために10 ^ 25/2300000000/60/60/24/365/1000 = 137 869〜ミリネアを信じます)。より強力なパスワードが必要な場合は、ソルトせずに、Diffie–Hellman鍵交換などを使用します。
シークレット2010

3

辞書攻撃の背後にある考え方は、ハッシュを取得し、ハッシュを計算せずに、このハッシュが計算されたパスワードを見つけることです。塩漬けのパスワードでも同じことをします-できません。

ソルトを使用しないと、データベースでの検索と同じくらい簡単にパスワードを検索できます。ソルトを追加すると、攻撃者は考えられるすべてのパスワードのハッシュ計算を実行します(辞書に添付されている場合でも、これにより攻撃時間が大幅に増加します)。


OPのシナリオでは、攻撃者データベースからソルトを取得し、「辞書」のすべてのエントリですべてのソルトを試す必要があります。...おもう。
frustratedWithFormsDesigner 2010

2

簡単に言うと、ソルトなしで、各候補パスワードを1回ハッシュするだけで、同じアルゴリズムを介してパスワードがハッシュされる「既知の宇宙」(侵害されたデータベースのコレクション)内のすべてのユーザーに対してパスワードをチェックできます。ソルトでは、可能なソルト値の数が「既知の宇宙」のユーザー数を大幅に超える場合、各候補パスワードは、テスト対象のユーザーごとに個別にハッシュする必要があります。


2

簡単に言えば、ソルティングはハッシュ(ブルートフォースまたは辞書)の攻撃を防ぐことはできず、それを難し​​くするだけです。攻撃者は、ソルティングアルゴリズム(適切に実装された場合、より多くの反復を使用する)を見つけるか、非常に単純でない限り、ほぼ不可能であるアルゴをブルートフォースする必要があります。ソルトはまた、レインボーテーブルルックアップのオプションをほぼ完全に破棄します...


1

塩はレインボーテーブルを作ります、単一のパスワードハッシュを解読するのをはるかに困難にするため攻撃をはるかに困難にします。数字が1の恐ろしいパスワードを持っていると想像してみてください。レインボーテーブル攻撃はこれをすぐに解読します。

ここで、データベース内の各パスワードが、多くのランダムな文字の長いランダムな値でソルトされていると想像してください。これで、お粗末なパスワード「1」が1のハッシュとランダムな文字(ソルト)の束としてデータベースに保存されるため、この例では、レインボーテーブルに次のようなハッシュが必要です。

したがって、ソルトが安全でランダムなものであると仮定すると、たとえば()%ISLDGHASKLU(%#%#)、ハッカーのレインボーテーブルには1 *()%ISLDGHASKLU(*%#%#のエントリが必要です。レインボーテーブルを使用するようになりました。この単純なパスワードでさえ、もはや実用的ではありません。


アップデート#2を参照してください。生のパスワードを取得し、各ユーザーレコードのソルトに対するすべてのハッシュを計算するだけです。
トムガレン2010

2
確かにトムは、私は同意するが、ポイントは、ハッカーが一度その醜い時間のかかるプロセスを行う必要があるため 、各塩が使用されている場合は、パスワード。したがって、塩はレインボーテーブルの使用を難しくします。
Cory House

3
@Tom Gullen:塩漬けのレインボーテーブルの生成は、サイト全体の塩が使用されている場合にのみ実行可能です。ユーザーごとのソルティングは、レインボーテーブル攻撃をほとんど役に立たないものにします。
スネマーチ2010
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.