105

職場では、塩について 2 つの競合する理論があります。私が取り組んでいる製品では、ユーザー名や電話番号などを使用してハッシュをソルトしています。基本的に、ユーザーごとに異なるものですが、私たちはすぐに利用できます。他の製品は、ユーザーごとにソルトをランダムに生成し、ユーザーがパスワードを変更するたびに変更します。その後、ソルトはデータベースで暗号化されます。

私の質問は、2 番目のアプローチが本当に必要かどうかです。純粋に理論的な観点からは、最初のアプローチよりも安全であることは理解できますが、実用的な観点からはどうでしょうか。現在、ユーザーを認証するには、ソルトを暗号化せずにログイン情報に適用する必要があります。

考えてみると、このアプローチによる実際のセキュリティの向上は見られません。アカウントごとにソルトを変更すると、攻撃者が各アカウントのソルトをすばやく判断する方法を知っていたとしても、誰かがハッシュ アルゴリズムをブルート フォースしようとすることは依然として非常に困難になります。これは、パスワードが十分に強力であることを前提としています。(明らかに、すべて 2 桁のパスワード セットの正しいハッシュを見つけることは、8 桁のパスワードの正しいハッシュを見つけるよりもはるかに簡単です)。私の論理が間違っていますか、それとも何かが欠けていますか?

編集：さて、ソルトを暗号化するのは本当に無意味だと思う理由は次のとおりです。（私が正しい軌道に乗っているかどうかを教えてください）。

以下の説明では、パスワードは常に 8 文字で、salt は 5 文字で、すべてのパスワードは小文字で構成されていると仮定します (計算が簡単になるだけです)。

エントリごとに異なるソルトを持つということは、同じレインボー テーブルを使用できないことを意味します (実際、技術的には、十分なサイズのテーブルがあれば使用できますが、それは今のところ無視しましょう)。これは、私が理解しているソルトへの本当の鍵です。なぜなら、すべてのアカウントを解読するには、いわばそれぞれのアカウントを再発明する必要があるからです。正しいソルトをパスワードに適用してハッシュを生成する方法を知っていれば、ソルトは実際にはハッシュされたフレーズの長さ/複雑さを拡張するだけなので、それを行います。したがって、ソルトが何であるかを知っているため、パスワード + ソルトを 13^26 から 8^26 に「知る」ために生成する必要がある可能な組み合わせの数を削減します。これで簡単になりましたが、それでも本当に難しいです。

それでは、ソルトの暗号化について説明します。ソルトが暗号化されていることがわかっている場合は、最初にそれを復号化しようとはしません (十分なレベルの暗号化があることがわかっている場合)。私はそれを無視します。それを解読する方法を見つけようとする代わりに、前の例に戻って、13^26 のすべてのキーを含むより大きなレインボー テーブルを生成します。ソルトを知らないと間違いなく遅くなりますが、最初にソルト暗号を解読しようとするという記念碑的なタスクが追加されるとは思いません. だからこそ、もったいないと思います。考え？

ブルート フォース攻撃に対してパスワードが保持される期間を説明するリンクは次のとおりです: http://www.lockdown.co.uk/?pg=combi

4

10 に答える 10

103

塩を隠す必要はありません。

ハッシュごとに異なるソルトを使用する必要があります。実際には、これは、暗号品質の乱数ジェネレーターから 8 バイト以上を取得することで簡単に実現できます。

私の以前の回答から：

Salt は、事前に計算された辞書攻撃を阻止するのに役立ちます。

攻撃者が可能性の高いパスワードのリストを持っているとします。彼はそれぞれをハッシュして、被害者のパスワードのハッシュと比較し、一致するかどうかを確認できます。リストが大きい場合、これには長い時間がかかることがあります。彼は次のターゲットに多くの時間を費やしたくないので、ハッシュが対応する入力を指す「辞書」に結果を記録します。パスワードのリストが非常に長い場合は、レインボー テーブルなどの手法を使用してスペースを節約できます。

しかし、彼の次のターゲットが彼らのパスワードをソルトしたとします。攻撃者がソルトが何であるかを知っていたとしても、事前に計算されたテーブルには何の価値もありません。ソルトは、各パスワードから得られるハッシュを変更します。彼は、リスト内のすべてのパスワードを再ハッシュし、ターゲットのソルトを入力に追加する必要があります。ソルトごとに異なるディクショナリが必要であり、十分な量のソルトが使用されると、攻撃者はそれらすべてのディクショナリを格納する余地がなくなります。時間を節約するためにスペースを交換することは、もはや選択肢ではありません。攻撃者は、攻撃したいターゲットごとに、リスト内の各パスワードのハッシュにフォールバックする必要があります。

したがって、塩を秘密にしておく必要はありません。攻撃者がその特定のソルトに対応する事前に計算された辞書を持っていないことを確認するだけで十分です。

これについてもう少し考えてみると、塩を隠すことができると思い込むのは危険であることに気付きました. ソルトを隠すことはできないと想定し、それにもかかわらずシステムを安全に設計する方がはるかに優れています。別の回答でより詳細な説明を提供します。

ただし、NIST からの最近の推奨事項では、追加の秘密の「塩」の使用が推奨されています (他の人がこの追加の秘密の「コショウ」と呼んでいるのを見たことがあります)。このシークレットをソルトとして使用して、キー導出の追加の反復を 1 回実行できます。このラウンドは、事前計算されたルックアップ攻撃に対する強度を高めるのではなく、優れたキー導出関数での多数の反復と同様に、パスワードの推測から保護します。このシークレットは、ハッシュ化されたパスワードと一緒に保存された場合、何の役にも立ちません。これはシークレットとして管理する必要があり、大規模なユーザー データベースでは難しい場合があります。

于 2008-10-18T15:28:19.650 に答える
45

ここでの答えは、自分が本当に何から保護しようとしているのかを自問することです。誰かがあなたのデータベースにアクセスできる場合、彼らは暗号化されたソルトにアクセスでき、おそらくあなたのコードにもアクセスできます. これで、暗号化されたソルトを解読できるでしょうか? もしそうなら、とにかく暗号化はほとんど役に立たない. 塩は本当にそれを作るためにあるので、レインボーテーブルを形成して、パスワードデータベース全体が侵入された場合に一度にクラックすることはできません. その観点から、各ソルトが一意である限り違いがないため、ソルトまたはパスワードごとに個別に暗号化されたソルトを使用したブルート フォース攻撃が必要になります。

于 2008-10-17T19:03:00.123 に答える
6

隠れた塩はもはや塩ではありません。胡椒です。それには用途があります。塩とは違います。

Pepper は、ハッシュを HMAC (Hash Based Message Authentication Code) にするパスワード + ソルトに追加された秘密鍵です。ハッシュ出力とソルトにアクセスできるハッカーは、理論的には、ハッシュを生成する入力をブルート フォースで推測できます (したがって、パスワード テキストボックスで検証に合格します)。ペッパーを追加することで、暗号学的にランダムな方法で問題の領域を増やし、本格的なハードウェアなしでは問題を扱いにくくします。

ペッパーの詳細については、こちらをご覧ください。

hmacも参照してください。

于 2013-10-10T21:16:34.810 に答える
3

「ソルト」についての私の理解は、クラッキングをより困難にするということですが、余分なデータを隠そうとはしません。ソルトを「秘密」にすることでセキュリティを強化しようとしている場合は、暗号化キーのビット数を増やす必要があります。

于 2008-10-17T18:57:24.033 に答える
3

2 番目の方法は、わずかに安全です。ソルトは、辞書攻撃やレインボー テーブル攻撃からユーザーを保護します。これにより、野心的な攻撃者がシステム全体を侵害することが難しくなりますが、システムの 1 人のユーザーに焦点を当てた攻撃に対しては依然として脆弱です。電話番号などの公開されている情報を使用し、攻撃者がこれに気付いた場合、攻撃を回避したことになります。もちろん、攻撃者がデータベース全体、ソルトなどすべてを取得するかどうかは問題ではありません。

編集:この回答といくつかのコメントを読み直した後、質問で提示された2つの非常に具体的なケースのみを比較しているため、混乱の一部が発生する可能性があることに気付きました:ランダムソルトと.非ランダムソルト。電話番号をソルトとして使用するという問題は、攻撃者がデータベース全体を取得する場合、ソルトを使用するという問題ではなく、議論の余地があります。

于 2008-10-17T19:05:39.103 に答える
3

...ユーザー名や電話番号のようなものでハッシュをソルトします。...

私の質問は、2 番目のアプローチが本当に必要かどうかです。純粋に理論的な観点からは、最初のアプローチよりも安全であることは理解できますが、実用的な観点からはどうでしょうか。

実用的な観点からは、ソルトは実装の詳細です。ユーザー情報の収集方法や維持方法を変更した場合 (正確な例を使用すると、ユーザー名と電話番号の両方が変更される場合があります)、セキュリティが侵害された可能性があります。このような外向きの変更に、より深いセキュリティ上の懸念を持たせたいですか?

各アカウントに電話番号が必要であるという要件を廃止するには、それらのアカウントをセキュリティ侵害にさらしていないことを確認するために、完全なセキュリティ レビューを行う必要がありますか?

于 2012-07-15T03:04:56.663 に答える
2

これは、ハッシュごとに同じソルトを使用することがなぜ悪いのかを示す簡単な例です。

次の表を検討してください

UserId  UserName,   Password
     1  Fred       Hash1 =  Sha(Salt1+Password1)    
     2  Ted        Hash2 =  Sha(Salt2+Password2)

salt1がsalt2と同じ 場合のケース1Hash2がHash1に置き換えられた場合、ユーザー2はユーザー1のパスワードでログオンできます。

ソルト1が同じソルト2ではない 場合のケース2Hash2がHash1に置き換えられた場合、user2はユーザー1のパスワードでログオンできません。

于 2008-10-17T19:14:50.817 に答える
1

目標が異なる2つの手法があります。

  • 「ソルト」は、他の点では等しい2つのパスワードを異なる方法で暗号化するために使用されます。このように、侵入者は暗号化されたパスワードのリスト全体に対して辞書攻撃を効率的に使用できません。

  • （共有）「秘密」はメッセージをハッシュする前に追加されるため、侵入者は自分のメッセージを作成して受け入れることができません。

于 2008-10-17T18:58:55.857 に答える
-1

実際、データを保護しようとしている攻撃の種類によって異なります。

パスワードごとに一意のソルトを使用する目的は、パスワードデータベース全体に対する辞書攻撃を防ぐことです。

パスワードごとに一意のソルトを暗号化すると、個々のパスワードを解読するのが難しくなりますが、実際に多くのメリットがあるかどうかを検討する必要があります。攻撃者がブルートフォースで次の文字列を見つけた場合：

Marianne2ae85fb5d

DBに格納されているハッシュへのハッシュですが、どの部分がパスで、どの部分がソルトであるかを理解するのは本当に難しいですか？

于 2008-10-17T19:16:43.137 に答える