3

私のデータベースには、ユーザーごとに一意のソルトが保存されています。

各ユーザーが独自のソルトを持っているアプリケーション用にphpでログインスクリプトを作成しています。ログインを実装する方法は次のとおりです。

  1. ユーザーが詳細を入力して送信
  2. ユーザー名が送信され、スクリプトが存在するかどうかを確認します
  3. そうでない場合は、そのユーザーのソルトを返します。それ以外の場合は、一般的なエラーが返されます

そのユーザーのソルトを返すスクリプトが必要です。そうしないと、ソルトなしでパスワードをハッシュして送り返すことができないときに、送信されたパスワードが正しいことをアプリがどのように確認するのでしょうか?

ここで、私が確信が持てないことがあります。ハッカーはソルトが何であるかを見て、パスワードハッシュを見て、それを使って何かをすることができるので、ソルトが暗号化されているかどうかは重要ですか. 送信する前にソルトを暗号化する必要がありますか?

以下の返信で何かを理解していない/見落としている可能性があります。

アドバイスが必要です。

4

1 に答える 1

1

ソルトがハッシュされているか、プレーンな文字列として残されているかは問題ではありません。重要な点は、パスワードをソルトすることで、辞書/レインボー テーブル攻撃を直接使用してパスワードをブルート フォース クラックすることを防ぐことです。追加の利点は、結果として各ユーザーが異なるハッシュ化されたパスワードを持つことです。

ソルトは、サーバー側で作成されるランダムに生成された文字列であり、ブラウザーとの間の送信は一切行いません。

サーバー上:

  // Password from form
  $pw = $_GET['password'];

  // Generate salt using unique values
  $salt = (rand(8).$registration_date.$username);

  // Password to be hashed
  $pwthb = ($pw.$salt);

ハッカーがデータベースへのアクセス権を取得した場合、ほとんどの場合、最初のランダム ソルトを保存して比較のためにハッシュする必要があるため、ゲームは終了します。

簡単な例:

  1. ユーザーは、登録時にブラウザで初期パスワードを入力します
  2. サーバー上で、パスワードは一意のソルトと組み合わされ、ハッシュされ、DB にパスワードとして保存されます
  3. SaltはDBに保存されます

注: ハッシュは、PHP または MySQL/DB 関数を使用して実行できます。

ユーザーが戻ったとき:

  1. ユーザーがブラウザにパスワードを入力する
  2. DB からソルトを取得し、入力したパスワードと組み合わせる
  3. パスワード+ソルトをハッシュし、保存/ハッシュされたパスワードと比較します
  4. 一致する場合: 認証する

さらに読むという点では、おそらく次のことを検討する価値があります。

于 2013-04-13T23:56:42.533 に答える