1. ホーム
  2. security

[解決済み] ハッシュのソルトを隠蔽する必要性

2022-12-11 17:12:50

質問

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

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

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

EDITです。 さて、ここで私が塩を暗号化するのは本当にムダだと思う理由を説明します。 (私が正しい軌道に乗っているかどうか教えてください)。

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

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

そこで、ソルトを暗号化することにします。 ソルトが暗号化されていることが分かっていれば、(十分な暗号化レベルであることが分かっていれば)まず解読しようとは思いません。 無視します。 復号化する方法を考える代わりに、前の例に戻って、13^26のすべてのキーを含むより大きなレインボーテーブルを生成するだけです。 ソルトを知らなければ、確かにスピードは落ちますが、ソルト暗号を最初に解読するという途方もない作業を追加することにはならないと思うのです。 だから、私はそれが価値があるとは思わないのです。 どうでしょう?

ブルート フォース攻撃で長いパスワードがどのくらい持ちこたえられるかを説明したリンクがあります。 http://www.lockdown.co.uk/?pg=combi

どのように解決するのですか?

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