なぜ塩はLinkedInのパスワードが解読されるのを防がなかったのですか？
この セキュリティに関するKrebsに投稿されたインタビュー では、この質問が尋ねられ、答えられました。
BK：他の人が言うには聞いたことがあると思いますが、LinkedInや他の人がパスワードをソルト化した場合、または各パスワードにランダム性を追加した場合、これはおそらく発生しなかったと考えられます。それに同意しますか？
Ptacek：それは実際には別の誤解です。問題は、パスワードが無塩であるということです。 UNIXパスワード。70年代からずっとソルトされており、永久に解読されています。パスワードにソルトを使用するという考えは、70年代の解決策です。 90年代に戻ると、人々がUNIXサーバーに侵入すると、シャドウパスワードファイルが盗まれて解読されます。常にサーバーを失ったとき、そのサーバーのパスワードを失いました。
Ptacekは実際には説明しません理由これは事実です-彼は塩が過去にこの種の攻撃を防いでいないとだけ述べています。
ソルトは、事前計算されたハッシュを格納するために必要なスペースがあるため、パスワードハッシュの事前計算のみを防止できると私は理解しています。しかし、システムが危険にさらされている場合は、saltとhashの両方が手に入ります。したがって、ハッシュを辞書攻撃する時間は大幅に変わりません（辞書の単語へのソルトの追加連結のみ）。
私の理解は正しいですか？
クレブスはこの質問をフォローアップし、プタチェクは彼が何を意味するのかを明確にします：
BK：わかりました。では、弱点が暗号アルゴリズムの強さにあるのではなく、ハッシュされたパスワードにソルトが追加されていないことにあるのではない場合、その答えは何でしょうか？
Ptacek：LinkedInの場合、および他の多くのサイトでは、問題は彼らが間違った種類のアルゴリズムを使用していることです。パスワードハッシュを使用する必要がある場合、暗号化ハッシュを使用します。
次のいくつかの段落では、その理由についても詳しく述べています。 SHA1はソルトの有無にかかわらず、パスワードハッシュとして使用するには速すぎます。非常に高速なので、GPUなどを使用して計算すると、毎秒数十万のハッシュをブルートフォースで処理できます。インタビューの後半で詳しく説明するように、 LinkedInはbcryptを使用しているはずです です。これは、ブルートフォースの時間を毎秒数10のハッシュのオーダーまで遅くする適応ハッシュです。
最初にソルトの質問を見て、次に速度の問題を見てみましょう。
塩、辞書攻撃、レインボーテーブル
塩は、攻撃者が複数のパスワードハッシュにアクセスする一般的なケースで、辞書攻撃を大幅に防止します。
塩がなければ、攻撃者はすべてのハッシュをソートします。彼はパスワードディクショナリから最初の単語をハッシュし、計算されたハッシュが盗まれたハッシュのソートされたリストにあるかどうかを確認します。少し運が良ければ、彼はすでに複数のアカウントにアクセスできました。
しかし、ソルトを使用すると、各アカウントを個別に攻撃する必要があります。
レインボーテーブルは、攻撃の前に行われ、すぐに使用できるという意味で、辞書攻撃の特別なケースにすぎません。
注意することが重要です：一定のランダムな文字列をすべてのパスワードに貼り付けると、事前に作成されたRainbowテーブルが役に立たなくなります。ただし、前述の並列処理の問題のため、はまだ悪い考えです。
スピード、ドキュメントのアルゴリズムとパスワードのアルゴリズム
ソルトを使用しないことに加えて、LinkedInは非常に高速なハッシュアルゴリズムを使用しており、特別なハードウェアで実行してさらに高速化することができます。この特別なハードウェアはエキゾチックではありませんが、一般的なグラフィックカードの一部です。
Robert David Grahamが クラッキング作業の詳細 を投稿しました。
Radeon HD 7970を使用して毎秒20億。6[文字]パスワード[in] 500秒[...]総当たり。
ハッシュアルゴリズムの元の使用例は、ドキュメントへの署名でした。したがって、高速であることは設計目標でした。
パスワードの最新のハッシュアルゴリズムは、比較的遅くなるように設計されています。それらを遅くする簡単な方法は、ハッシュ関数を繰り返し使用することです。 ShaCryptおよびBCryptはそのようなアルゴリズムです。彼らは、並列処理を防止し、単一のラウンドでのプリイメージ攻撃に対して耐性があるように特別な注意を払います。
Scryptはこれをさらに一歩進めます：低速であることに加えて、たくさんのメモリを必要とします（たとえば、デフォルトの構成では16 MB） ）。専用ハードウェアは通常、約1 KBの高速内部メモリにしかアクセスできません。コアメモリへのアクセスが遅い。したがって、ハードウェアで高速の暗号解読プログラムを構築すると、非常に早く費用がかかります。
あなたは正しいですが、塩を使用することが不可欠であるという事実は変わりません。この場合、攻撃者はハッシュされたパスワードを入手したため、レインボーテーブルを使用するか、ブルートフォース攻撃または辞書攻撃を開始できます。
レインボーテーブルを使用すると、非常に短い時間ですべてのパスワード（テーブルのサイズと複雑さまで）を取得できます。
同様に、辞書攻撃は辞書にあるパスワードを取得します。
ブルートフォーシングを使用すると、短くて単純なパスワードをすばやく取得できますが、長いパスワードを取得するのにかかる時間は非常に長くなるため、長いパスワードを使用するユーザーは依然として比較的安全です。
したがって、ソルトはその最初の可能性を取り除き、攻撃者に辞書とブルートフォースソリューションの使用を強いる-ユーザーをより安全にする。
ソルトは何をしているのかというと、レインボーテーブルが役に立たなくなり、ブルートフォースによるパスワードの試行が遅くなります。
レインボーテーブルの定義：
レインボーテーブルは、通常はパスワードハッシュを解読するために、暗号化ハッシュ関数を元に戻すための事前計算されたテーブルです。
ソルトがなければ、攻撃者は、何百万ものパスワードとハッシュされた同等のものを含む事前に生成されたRainbowテーブルを簡単に使用し、それをパスワードと比較することができます。
Saltを使用すると、攻撃者はすべてのパスワードでまったく新しいRainbowテーブルを生成する必要があります。
辞書攻撃には影響しません-パスワードのような簡単で明白な辞書ベースのパスワードは、ソルトの有無にかかわらず簡単にクラックされます。
ただし、塩を使用する必要があります。パスワードクラッキングは時間と労力がすべてです。無敵のパスワード/ハッシュはありません。攻撃者がパスワードテーブルに費やすよりも多くの時間を費やすようにすることがすべてです。
塩は並列処理を妨げます。並列処理は、時空全体で一般的です。これにより、space-wiseおよびtime-wiseを適用できることを意味します。
スペースごとの並列処理は、攻撃者がクラックするハッシュをいくつか持っている場合です（LinkedInの状況です）。無塩ハッシュを使用すると、攻撃者は1つの潜在的なパスワードをハッシュし、解読したいハッシュのリスト全体から結果を調べることができます。
時間ごとの並列処理は、攻撃者が一般的なパスワードのハッシュを大きなテーブル（レインボーかどうかにかかわらず）に事前計算して、ハッシュその後が取得します。
プタチェクが意味したのは、
塩は仕事の半分しかしません。攻撃者を本当に遅くするには、 bcrypt のような本質的に遅いハッシュプロセスが必要です。
多くのユーザーがいる場合、ソルトされた暗号化の量に関係なく、パスワードの少なくとも一部は非常に弱くなり、クラックされます。
そのため、ソルトはLinkedInの状況をいくらか改善しましたが、保存されず、遅延が生じ、問題が多少緩和されました。 bcryptまたはPBKDF2を使用するとさらに改善されますが、侵害を完全に無視できるほどではありません。
Ptacekは実際には、ソルトがLinkedInパスワードのクラックを防止できなかったとは言っていません。 saltのサイズによっては、最悪のパスワードを保護することさえできると私は主張する必要があります。
SHA1の1つの弱点は、ブルートフォース攻撃に対する弱点です。事前にXハッシュを生成し、文字列のSHA1ハッシュの値を生成されたハッシュのリストと比較するだけです。
リストを事前に生成するためにサイズに依存するソルトを使用すると、非常に長い時間がかかり、大量のディスクストレージが必要になります。 可能なすべてのソルトに対して同じリストを生成する必要があることを覚えておく必要があります。この時点での唯一の希望は、すべての組み合わせを試し、一致を見つけることです。 ソルトをデータベースに保存せずにユーザーごとに一意のソルトを生成できる場合は、さらに安全です
言い換えれば、...すべてのパスワードがクラックされる代わりに... LinkedInは、漏えいしているユーザーのパスワードの非常に小さいパーセンテージのみを見ていることになります（最悪の最悪）。
更新
鍵はどこに保管しますか？
正しい方法で行った場合は、保存する必要はありません。アカウントが作成されたときのユーザー名、またはその2つの組み合わせに基づいてソルトを生成するだけで、特定のユーザーに固有のソルトが作成されます。
そのため、Webサイト自体のソースが漏洩しない限り、ハッカーはそれを生成できません。ユーザーがアカウントのパスワードを変更したときに、これをさらに安全にし、新しいソルトを生成することもできます。
盗まれたデータベーステーブルを持つ人は、ユーザーごとに2つのフィールドしかありません。
_password hash salt
c32528b3e9191a8c7471252c6de289939a1e6f01 cGFzc3dvcmQ
_最も基本的な用語では、私が理解しているようにソルティングが行うことはすべて、パスワードをより長くすることです。
元のパスワードは「password」でした。しかし、ハッシュ__cGFzc3dvcmQ_を計算して_passwordcGFzc3dvcmQ_にするために、ハッシュを計算する前にパスワードに追加しました。それは何をしますか？まあ、それはちょうどそれを作るので、あなたがたまたま一般的なパスワードとそのハッシュのレインボーテーブルを持っているなら、
_password hash
password 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8
_一目でSHA('password')=5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8を確認できるところ、ハッシュから元のパスワードを検索するのは非常に単純です。私たちはクラッカーがそれのためにいくつかの仕事をしなければならないことを望みます。
そこで、「Dyoh！元のパスワードの右側にこのランダムな文字列を追加または追加しました！これで、共通パスワードとそのハッシュのハッシュテーブルが役に立たない」
彼らはどちらですか。各パスワードをランダムな文字列で複雑にしたため、基本的には「ユーザーのパスワードを改善する」ため、ハッシュを完全にねじ込んで、今ではまったく一般的ではありません。
だから塩漬けはそうする各ハッシュを個別にクラックする必要があります、それを行うには、クラッカーが塩を持っている場合、クラッカーが追加/追加する必要があるからです共通のパスワードへのソルトは、彼が試みます。 2人の異なるユーザーが単純なパスワードpasswordを使用する可能性がありますが、ソルトのため、クラッキングはクラッカーにとって2つの完全に別のジョブになります。そのため、すべてのパスワードの解読には時間がかかります。
こちらの記事 は、現在利用可能な計算能力のために、ソルトを使用しても簡単に解読できると述べています。