ソルト文字列はどこに保存しますか？
データベースストレージのパスワードをハッシュするときは、常にエントリごとに適切なソルト文字列を使用しました。私のニーズに合わせて、ハッシュされたパスワードの隣のDBにソルトを保存することは常にうまくいきました。
ただし、一部の人々は、データベースとは別にソルトを保存することを推奨しています。彼らの主張は、データベースが危険にさらされた場合でも、攻撃者は特定のソルト文字列を考慮してRainbowテーブルを構築し、一度に1つのアカウントをクラックできるということです。このアカウントに管理者権限がある場合、他のアカウントをクラックする必要さえありません。
セキュリティの観点から、塩を別の場所に保存する価値はありますか？同じマシン上のサーバーコードとDBを使用するWebアプリケーションを検討してください。塩がそのマシンのフラットファイルに保存されている場合、データベースが危険にさらされた場合、塩ファイルも同じである可能性があります。
これに対する推奨される解決策はありますか？
レインボーテーブルのポイントは、事前に作成され、他のユーザーの計算時間を節約するためにまとめて配布されることです-その場でレインボーテーブルを生成するには、パスワードと塩の組み合わせを直接クラックするのと同じくらい時間がかかります（事実上、Rainbowテーブルを生成するときに行われていることは、ブルートフォースハッシュの計算を事前に実行しているため）、塩を知ることで誰かが「Rainbowテーブルを生成する」ことができるという議論は偽物です。
ユーザーごとにある限り、ソルトを別のファイルに保存することには実質的な意味はありません。ソルトのポイントは、1つのRainbowテーブルがDB内のすべてのパスワードを解読できないようにすることです。
これについて少し異なる見解を提供します。
私は常に、ソルトパスワードハッシュとソルトを混ぜて保存します。
たとえば、ソルトの前半をパスワードのソルトハッシュの前に配置し、ソルトの後半をパスワードのソルトハッシュの後に配置します。アプリケーションはこの設計を認識しているため、このデータをフェッチして、ソルトおよびソルトパスワードハッシュを取得できます。
このアプローチの私の理論的根拠：
パスワード/ハッシュデータが危険にさらされて攻撃者の手に渡った場合、攻撃者はデータを見て塩が何であるかを知りません。この方法では、攻撃者はブルートフォース攻撃を実際に実行してハッシュに一致するパスワードを取得することはできません。最初にハッシュを知らず、データのどの部分がソルトの一部であるかを知る方法がないため、またはソルテッドパスワードハッシュの一部（アプリケーションの認証ロジックを知らない限り）.
ソルテッドパスワードハッシュがそのまま保存されている場合、ブルートフォース攻撃を実行して、ソルトおよびハッシュされたときにソルトパスワードハッシュと同じデータを生成するパスワードを取得できます。
ただし、たとえば、ソルトパスワードハッシュがそのまま保存されていて、ランダムな1バイトが事前に追加されている場合でも、攻撃者がこの最初のバイトが破棄されることを知らない限り、これも難易度を高めます攻撃の。ユーザーの認証に使用する場合、アプリケーションはデータの最初のバイトを破棄することを知っています。
これに対する結論..
1）認証アプリケーションが使用するデータを正確な形式で保存しないでください。
2）可能であれば、セキュリティを強化するために認証ロジックを秘密にしてください。
さらに一歩進む..
アプリケーションの認証ロジックを秘密にできない場合-多くの人々は、データがデータベースに保存される方法を知っています。そして、ソルトと一緒にソルトパスワードハッシュを保存し、ソルトの一部がソルトパスワードハッシュの先頭に追加され、ソルトの残りがそれを追加することにしたと仮定します。
ランダムソルトを生成するとき、ソルトパスワードハッシュの前後に保存するソルトの割合をランダムに決定することもできます。
たとえば、512バイトのランダムソルトを生成します。パスワードにソルトを追加し、ソルトパスワードのSHA-512ハッシュを取得します。また、ランダムな整数200を生成します。次に、ソルトの最初の200バイトを格納し、その後にソルトパスワードハッシュ、ソルトの残りを格納します。
ユーザーのパスワード入力を認証するとき、アプリケーションは文字列を渡し、データの最初の1バイトがソルトの最初の1バイトであり、その後にソルトハッシュが続くと想定します。このパスは失敗します。アプリケーションは、データの最初の2バイトをソルトの最初の2バイトとして使用して続行し、最初の200バイトをソルトの最初の200バイトとして使用した後、肯定的な結果が見つかるまで繰り返します。パスワードが間違っている場合、アプリケーションは、何も見つからないまですべての順列を試行し続けます。
このアプローチの長所：
強化されたセキュリティ-認証ロジックがわかっていても、正確なロジックはコンパイル時に不明です。正確なロジックを知っていても、ブルートフォース攻撃を実行することは事実上不可能です。ソルトの長さを長くすると、セキュリティがさらに向上します。
このアプローチの短所：
正確なロジックは実行時に推測されるため、このアプローチは非常にCPUを集中的に使用します。ソルトの長さが長いほど、このアプローチはCPUを集中的に使用します。
間違ったパスワードを認証すると、CPUコストが最も高くなります。これは、正当なリクエストに対して逆効果になる可能性がありますが、攻撃者に対するセキュリティが向上します。
このアプローチはさまざまな方法で実装でき、可変幅ソルトおよび/またはソルトパスワードハッシュを使用することでさらに安全にできます。
多くの場合、それらはハッシュの先頭に追加され、同じフィールドに保存されます。
それらを個別に保存する必要はありません-ポイントは、パスワードハッシュのセット全体に対して単一のRainbowテーブルを使用できないように、各パスワードにランダムなソルトを使用することです。ランダムソルトを使用すると、攻撃者は各ハッシュを個別にブルートフォースする必要があります（または、考えられるすべてのソルトのレインボーテーブルを計算します-非常に多くの作業が必要です）。
より安全な保管場所がある場合、ハッシュをそこに保管するだけの意味があります。
William Penberthy著 『ASP.NET MVC 4 Webアプリケーションの開発』に基づいています。
- 別のデータベースに保存されているソルトにアクセスするには、ハッカーが2つの異なるデータベースをハッキングして、ソルトとソルトパスワードにアクセスする必要があります。それらをパスワードと同じテーブル、または同じデータベースの別のテーブルに保存すると、ハッカーがデータベースにアクセスすると、ソルトとパスワードハッシュの両方にアクセスできるようになります。セキュリティには、システムへのハッキングが高価すぎたり時間を費やして価値がなかったりするプロセスが含まれているため、ハッカーが獲得しなければならないアクセス量を2倍にすると、システムがより安全になります。
- 使いやすさが、ハッシュされたパスワードと同じデータベースにソルトを保持する主な理由です。 2つのデータベースが常に同時に使用可能であり、常に同期していることを確認する必要はありません。各ユーザーがランダム化されたソルトを持っている場合、ソルトを使用する利点は最小限に抑えられます。個人のパスワードを簡単に発見できる可能性はありますが、システム全体のパスワードを解読するのに必要な力は大きくなるためです。このレベルの議論では、実際に期待されているのは、パスワードを保護することです。ハッカーがデータベースのコピーを取得している場合、アプリケーションデータはすでに侵害されています。この時点での問題は、パスワードを共有する可能性があるため、ユーザーのリスクを軽減することです。
- 2つの個別のリンクされたデータベースを維持する要件は広範囲に及びます。確かに、セキュリティの認識を追加しますが、それが提供する唯一の利点は、データの単一要素であるパスワードを保護することです。データベース内のすべてのフィールドが個別に暗号化され、同じソルトがそのために使用される場合、システムの基本的なセキュリティが強化されるため、データとは別に保存する方が理にかなっています。
ソルトのポイントは、すべてのRainbowテーブルを役に立たなくし、それらの新しいセットを作成する必要があることです。 Rainbowテーブルを作成するのと同じくらい文字列を推測するのに時間がかかります。たとえば、「パスワード」のSHA-256ハッシュは5e88 4898 da28 0471 51d0 e56f 8dc6 2927 7360 3d0d 6aab bdd6 2a11 ef72 1d15 42d8です。 「badpassword」などのソルトが追加されると、ハッシュされる新しい文字列は「passwordbadpassword」になります。これは、雪崩の影響により、出力を劇的に457b f8b5 37f1 802e f9c8 2e46 b8d3 f8b5 721b 7cbb d485 f0bb e523 bfbe 73e6 58d6に変更します。
通常、塩はパスワードと同じデータベースに保存されます。これは、一方のデータベースがハッキングされた場合、もう一方もハッキングされる可能性が高いためです。