ソルト、ハッシュされたパスワードストレージをプレーンテキスト、ノンス、ハッシュベースの認証と組み合わせるにはどうすればよいですか？
私の理解は次のとおりです。
パスワードを（データベースなどに）安全に保存するには、この目的のために設計された（低速になるように設計された（bcryptなど））ハッシュアルゴリズムを使用し、パスワードごとに一意のソルトを使用します。これにより、データベースにアクセスできる攻撃者がRainbowテーブルを使用できず、ブルートフォースの試行ごとに単純なmd5またはsha1よりも時間がかかるため、攻撃者はパスワードを回復するのが難しくなります。
プレーンテキストプロトコル（つまり、SSLではない）でパスワードを安全に認証するために、サーバーはクライアントにナンスを送信し、クライアントはパスワードとナンス（およびタイムスタンプも）を組み合わせ、ハッシュアルゴリズムを実行します。そのハッシュをサーバーに送信し、サーバーは同じアルゴリズムを実行して比較します。これにより、パスワードをプレーンテキストで送信することが回避され、サーバーが同じナンスを2回受け入れるようにだまされない限り、リプレイ攻撃が不可能になります。
問題は、これの認証部分では、サーバーが実際の平文パスワードを知っている必要があることです。したがって、＃1のように安全に保管することはできません。
これで、サーバーはソルトをクライアントに送信でき、クライアントはソルトされたハッシュされたパスワードを最初に計算してから＃2を実行できます。しかし、ソルトハッシュされたパスワードは実質的にプレーンテキストのパスワードになるため、実際には＃1はありません。
だから私の質問は、＃1と＃2の両方を行う方法はありますか？
はい、可能です。説明されている2つのアルゴリズムがあります here どちらもサーバーにプレーンテキストと同等のものを保存する必要を回避します（プレーンテキストパスワードをネットワーク経由で送信する必要なしに認証を可能にします）。
Secure Remote Passwordプロトコル（ wikipedia 、 Stanford ）を見てください。それはクライアント側でパスワードのハッシュを使用します（お気に入りの遅いソルトハッシュを選びます）が、サーバーは「ベリファイア」だけを取得します派生元離散指数によるそのハッシュ実際の認証は、2つの乱数（1つはクライアント生成、1つはサーバー生成）、ハッシュ（クライアント側のみ）、および検証（サーバー側）を使用する非対称鍵交換によって行われます。生成されたキーを使用して残りのセッションを暗号化することを目的としていますが、単純に検証して破棄することもできます。
利点：
- 鍵交換自体は事実上ゼロ知識証明です。つまり、リスナー、中間者、またはサーバーの詐欺師はパスワードに関する情報を取得しません。これらが可能な唯一のタイプの攻撃である場合、1文字のパスワードでセキュリティを確保できます。
- オンライン辞書攻撃（クライアント詐欺師）は、1回の試行で1つのパスワードしかテストできません（プロトコルの初期バージョンでは2つ許可されていました）。
- 攻撃者がサーバーの検証者のデータベースをコピーした場合、低速のハッシュand指数を介して各候補パスワードを実行することによってのみオフライン辞書攻撃を実行できます。ベリファイアを使用してクライアントを偽装することはできません。
- サーバーのベリファイアが秘密に保たれている限り、Exchangeトランザクションはサーバーからクライアント（およびクライアントからサーバー）に対して効果的に検証します。
私が間違っている場合は修正してください。ただし、ハッシュ化されたパスワードをサーバーに保持できます。安全に保管されています。そして、ナンスを認証のソルトとして使用します。私が目にする1つの大きなことは、サーバーがこのようにプレーンテキストのパスワードを知る必要がないことです。それでも、その人が正しいパスワードを入力したことを証明できますが、平文ではなくハッシュを比較することで確認できます。このシナリオでこのパスワードがプレーンテキストになる唯一の場所は、ハッシュされる前に（2回、プレーンと既知のソルトで2回）Webブラウザーウィンドウであり、プレーンテキストではなくネットワーク経由で送信されます。
以下のシナリオを検討してください
- クライアントが接続を試みます
- サーバーはナンスを生成します
- サーバーはnonceをクライアントに送信します。ハッシュを再び塩としてノンスでハッシュします。パスワードのハッシュを入力として受け取り、ノンスをソルトとして受け取るハッシュ。
- クライアントはpwdを同じハッシュアルゴリズムでハッシュし、サーバーに格納されるのと同じハッシュを生成します。
- 次に、クライアントは、サーバーが行ったのと同じように、それ自体の個別のハッシュを行います（ナンスをソルトとするpwdのハッシュのハッシュ）
- クライアントはサーバーにnoncedハッシュを送信します。
- サーバーはそれをその1回の認証時間に対して正しいものとして受け入れ、同じnoncedハッシュを再び受け入れることはありません