ハッシュのためにソルトを隠す必要性

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

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

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

編集：わかりましたので、ここで、ソルトを暗号化するのは本当に難しいと思う理由です。（私が正しい軌道に乗っているかどうかはわかります）。

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

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

ソルトの暗号化に移ります。ソルトが暗号化されていることがわかっている場合は、最初にそれを解読しようとはしません（十分なレベルの暗号化があることを前提として）。無視します。それを解読する方法を理解する代わりに、前の例に戻って、13 ^ 26のすべてのキーを含むより大きなレインボーテーブルを生成します。ソルトを知らないと間違いなく私は遅くなりますが、ソルトの暗号化を最初に解読しようとするという記念すべき仕事が増えるとは思いません。だからそれだけの価値はないと思います。考え？

以下は、ブルートフォース攻撃を受けた場合のパスワードの保持期間を説明するリンクです。http： //www.lockdown.co.uk/？pg = combi

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

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

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

私の以前の答えから：

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

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

ただし、彼の次のターゲットがパスワードを塩漬けにしたとします。攻撃者がソルトが何であるかを知っていても、事前に計算されたテーブルは役に立ちません。ソルトは各パスワードから得られるハッシュを変更します。彼は自分のリストにあるすべてのパスワードを再ハッシュし、ターゲットのソルトを入力に付加する必要があります。ソルトごとに異なるディクショナリが必要です。十分なソルトが使用されている場合、攻撃者はそれらすべてのディクショナリを保存する余裕がありません。時間を節約するための取引スペースはもはやオプションではありません。攻撃者は、攻撃したいターゲットごとに、リスト内の各パスワードをハッシュする必要があります。

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

これについてもう少し考えた後、塩を隠すことができると思い込んで自分をだますのは危険だと気づきました。塩を隠すことはできないと想定し、それにもかかわらずシステムが安全になるように設計することをお勧めします。別の回答でより詳細な説明を提供します。

ただし、NISTからの最近の推奨では、追加の秘密の「塩」の使用が奨励されています（他の人がこの追加の秘密を「コショウ」と呼ぶのを見たことがあります）。この秘密をソルトとして使用して、鍵導出の追加の反復を1つ実行できます。このラウンドは、事前に計算された検索攻撃に対する強度を高めるのではなく、優れた鍵導出関数での多数の反復のように、パスワードの推測から保護します。このシークレットは、ハッシュ化されたパスワードとともに保存された場合は意味がありません。シークレットとして管理する必要があり、大規模なユーザーデータベースでは困難な場合があります。

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

2番目のアプローチは、ほんの少しだけ安全です。ソルトは、辞書攻撃やレインボーテーブル攻撃からユーザーを保護します。彼らは野心的な攻撃者がシステム全体を危険にさらすことを難しくしますが、システムの1人のユーザーに焦点を当てた攻撃に対して依然として脆弱です。電話番号などの公開されている情報を使用していて、攻撃者がこれに気づいた場合、攻撃の一歩を踏み出したことになります。もちろん、攻撃者がデータベース全体、ソルトなどすべてを入手した場合、問題はありません。

編集：この回答といくつかのコメントをもう一度読んだ後、いくつかの混乱は私が質問で提示された2つの非常に特定のケースのみを比較しているという事実に起因しているかもしれないと思います：ランダムソルトと非ランダムな塩。電話番号をソルトとして使用するという問題は、攻撃者がデータベース全体を取得する場合には問題ではなく、ソルトを使用するという問題ではありません。

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

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

実用的な観点から見ると、ソルトは実装の詳細です。ユーザー情報の収集または保守の方法を変更した場合、およびユーザー名と電話番号の両方を変更して、正確な例を使用した場合は、セキュリティが低下している可能性があります。このような外向きの変更により、セキュリティの懸念をさらに深めたいですか？

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

隠された塩はもはや塩ではありません。コショウです。それには用途があります。塩とは違います。

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

コショウの詳細については、こちらをご覧ください。

hmacも参照してください。

これは、ハッシュごとに同じソルトを持つことが悪い理由を示す簡単な例です

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

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

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

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

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

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

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

私は塩を隠しがちです。ハッシュする前に、パスワードの先頭に1から1024までの乱数を付加して、10ビットのソルトを使用しています。ユーザーが入力したパスワードとハッシュを比較するとき、1から1024までループし、一致するものが見つかるまで、saltの可能なすべての値を試します。これは1/10秒未満かかります。私は、PHPのpassword_hashとpassword_verifyからこの方法でそれを行うというアイデアを得ました。私の例では、10ビットのソルトの「コスト」は10です。あるいは、他のユーザーが言ったことから、隠された「塩」は「コショウ」と呼ばれます。ソルトはデータベースで暗号化されていません。それは野蛮な強制です。これは、ハッシュを1000倍逆にするために必要なレインボーテーブルを作成します。sha256は高速なので安全です。

本当に、それはあなたがあなたのデータを保護しようとしている攻撃のタイプから依存します。

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

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

Marianne2ae85fb5d

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