web-dev-qa-db-ja.com

ソルトされた後、システムはハッシュ関数を使用してユーザーをどのように認証しますか？

塩漬けの仕組みがよくわかりません。 Wikipediaの記事 を読みましたが、システムがソルトハッシュを認証する方法をまだ理解できません。

ユーザーがパスワードを選択するとします。ランダムにソルト処理され、ハッシュ化されます。これで、そのユーザーが再度ログインするときに、パスワードが再度ハッシュされ、前回保存されたソルトおよびハッシュされたパスワードと比較されます。ハッシュは一致しませんか？

つまり、彼らは何らかの方法で一致することを推測します。しかし、どうやって？

passwordsauthenticationhashsalt
5
Npv23g

パスワードを最初にハッシュするとき（ユーザーが登録するとき）は、saltを使用し、saltと結果のハッシュの両方をデータベースに格納します。

2回目（彼らが再度ログインしようとしたとき）は、ユーザー名を使用してソルトとハッシュをデータベースから引き出します。 saltを使用してパスワード入力をハッシュし、2つのハッシュを比較します。

「誰かが私のデータベースにアクセスする場合、彼らはすべての塩を持っている-これは大きな問題ではありませんか？」と疑問に思うかもしれません。彼らがソルトを持っているという事実は問題ではありません。ソルトの目的は何か「秘密」を追加することではないので、2人のユーザーが同じパスワードを持っている場合に確認することです彼らは異なるハッシュを持っています =ハッシュが異なる塩で作成されたため。

ソルトを使用しなかった場合、またはすべてのユーザーにまったく同じソルトを使用した場合（残念ながら珍しい間違いではありません）、多くの重複したハッシュが発生します（同じパスワードを使用する人がいるため、これらの同一のパスワードはすべてが同じハッシュを持っています）。誰かがデータベースにアクセスした場合、彼らは最も頻繁に出現するハッシュを探し、それらのハッシュのクラックに集中できます。そして、各ハッシュをクラックして、複数のアカウントにアクセスできます。各ハッシュを異なる方法でソルト処理することで、ハッシュが重複しない可能性が非常に高くなります。異なるソルトは、重複したパスワードでも異なるハッシュを持つことを意味します。解読するハッシュごとに、1つのアカウントにアクセスできます-それ以上はアクセスできません。それが塩の目的です。

14
Chris

ソルトはハッシュと一緒に、たとえば別のデータベースフィールドに格納されるか、ハッシュの最後にタグ付けされるか、ユーザー名がソルトとして使用されます。

目的は、2人のユーザーが同じパスワードを持っている場合でも、そのソルトが異なり、そのため、ハッシュが同じにならないようにすることです。

これは、誰かがデータベースを盗むことができた場合に役立ちます。ハッシュとソルトの各組み合わせを個別にクラックする必要があります。したがって、同じパスワードを共有する2人のユーザーの場合、攻撃者は、両方を解読するまで同じであることを知りません。

また、saltがなければ、攻撃者が一般的なパスワードのハッシュを生成して、盗んだデータベースと照合することもできます。ソルティングはこれらの生成されたレインボーテーブルを役に立たなくします。

4
user2675345

これまでのところ素晴らしい回答ですが、あなたが参照した記事からはあまり明確ではないので、私も言及する必要があると思います。ハッシュ関数は、パスワードとともに連結されたソルトに対して実行され、ソルトは、関数から得られたハッシュで再度連結され、その文字列は、/ etc/shadowのようなパスワードデータベースに格納されます。

実際の例

この例は、ユーザーがUnixシステムでパスワードを選択したときに何が起こるか、/ etc/shadowにどのように保存されるか、そしてユーザーがログインするときにパスワードがどのようにチェックされるかを示しています。変数名の代わりに実際の例を使用しますまたはfoobarのような文字列。また、これを少し簡単にするために、pamのようなものは無視します。

  1. ユーザー「munroe」はpasswdプログラムを実行し、パスワード「HorseStapler + 5」を選択します
  2. Passwdプログラムはパスワードを受け取り、それをチェックして（妥当性ルールがないか）、ハッシュに使用する必要のあるアルゴリズムを決定します（DES、MD5、SHA-256、SHA-512）システムがSHA-512を選択するとしますハッシュアルゴリズム。
  3. SHA-512アルゴリズムは、英数字+ '。'で構成されるソルトに16文字のランダム文字列を使用します。および '/'。システムはランダムなソルト文字列「BohpaS.aul0Qua/t」を生成します。
  4. システムはこの 'HorseStapler + 5BohpaS.aul0Qua/t'のようにソルトをパスワードに連結します。これは、実際にハッシュされて保存される「新しい」平文です。それはそれをよりユニークにするので、その人気のために、パスワード「HorseStapler + 5」を使用する他の誰もがパスワードデータベースに同じハッシュテキストをもたらさないでしょう。また、レインボーテーブル攻撃から保護します。
  5. システムは新しい文字列SHA512（ 'HorseStapler + 5BohpaS.aul0Qua/t'）でハッシュアルゴリズムを実行し、ハッシュテキスト出力 'IVUen1dSKZ634jM.KLQ1Am/WPh..DSO2MYI53qffac2IFzESKwIufyVjzQGlxNenOXGehMTCLmd9LLP9eLPD9LLP9dMLP6d9LmDLPZeLPLP6dMLP
  6. システムが将来ユーザーを認証できるように、/ etc/shadowファイルで使用されるハッシュのタイプのインジケーターと同様に、そのユーザーのエントリの2番目のフィールド（暗号化フィールド）に次の文字列としてソルトを格納しますこの「$ 6 $ BohpaS.aul0Qua/t $ IVUen1dSKZ634jM.KLQ1Am/WPh..DSO2MYI53qffac2IFzESKwIufyVjzQGlxNenOXGehMTCdSoL9DLPe6Zfm1」

/ etc/shadowの完全なエントリは次のようになります。

munroe:$6$BohpaS.aul0Qua/t$IVUen1dSKZ634jM.KLQ1Am/WPh..DSO2MYI53qffac2IFzESKwIufyVjzQGlxNenOXGehMTCdSoL9DLPe6Zfm1:15196:0:99999:7:::

$ 6 $の部分は、SHA-512ハッシュされたことを示しています。 2番目と3番目の「$」文字の間の部分には、使用されたソルトが格納されます。シャドウファイルのこのフィールドは、暗号化フィールドと呼ばれます。暗号化されていないハッシュ化されているため、一部の人々はその名前を好まない。暗号化されているとは、復号化できることを意味しますが、復号化はできません。ただし、暗号化されたパスワードフィールドと呼びます。

再認証

  1. ユーザーmunroeが次にシステムにログインするときに、パスワード「HorseStapler + 5」を送信します。
  2. システムは/ etc/shadowでユーザーを検索し、上記の完全な文字列を見つけます。システムはそのソルト部分（2番目と3番目の '$'の間の部分）を取得し、上記のようにパスワードと連結します。次に、SHA-512アルゴリズムを使用して、1番目と2番目の「$」の間のアルゴリズム指定子「6」で示されているようにハッシュします。
  3. 次に、システムは結果のハッシュテキストを、シャドウファイルの暗号化されたパスワードフィールドの3番目の「$」の後の文字列と比較します。

うまくいけば、これは、ハッシュアルゴリズムが一方向のアルゴリズムである必要がある理由と、ソルトがどのように使用されるかを示しています。

シャドウファイルの理由は、/ etc/passwordファイルがUNIXシステムで誰でも読み取り可能である必要があるためです。昔、彼らは暗号化されたパスワード（および非常に昔には平文のパスワードも）を/ etc/passwordファイルの2番目のフィールドに保管していた。彼らはそれをシャドウファイルに移動し、そのファイルへのルートアクセスのみを与え、認証メカニズムはあなたを認証するためにルート権限を必要とします。

ええと、思ったよりずっと長くなってしまいました。

3
deltaray

ユーザーは常に実際のパスワードをサーバーに送信し、サーバーはソルト値とハッシュ値を保存します。ソルトの要点は、DBが危険にさらされている場合に、攻撃者がすべてのパスワードを一度に総当たりすることはできないことを確認することです。また、再利用されたパスワードの識別を防ぎます。

一致するまですべてのパスワードを試す必要があるだけなので、ソルトを知っていても攻撃者の作業を減らすことはないので、ソルトが公の知識になってもかまいません。ハッシュはサーバー上で行われるため、クライアントは実際にパスワードを知らなくても、DBに表示されるハッシュを簡単に返すことができません。

2
AJ Henderson