クライアント認証の基本を理解するための認証メカニズムの実装
ユーザーを認証し、ログインフォームを介して特定のWebページ/リソースへのアクセスをユーザーに許可するための簡単なプロトコルを実装しようとしています。
これは私自身で使用するためのものであり、そのようなシステムがどのように機能するかについての基本的な考え方を理解するためのものであることに注意してください。
私の考えは、サーバー側のサーバーとクライアント間の共有シークレットのハッシュを保存し、チャレンジ/レスポンスメカニズムを使用してユーザーを認証することです。ユーザーがユーザー名を入力すると、サーバーはチャレンジに応答し、共有シークレットを使用してリソースにアクセスできることを意味します。たとえば、パスワードとチャレンジをハッシュ化してサーバーに送り返します。サーバーはユーザーの保存されたパスワードと同じことを行い、両方の値が同じかどうかを確認します。
しかし、ユーザーCがサーバーへのAの応答を傍受し、それをCであるかのようにサーバーに送信できるとしたら、これはどのようにしてユーザーAをサーバーBに対して認証できますか？次に、サーバーはCにリソースAへのアクセスを許可することを承認します。
これは、CHAPやEAPなどのプロトコルが機能する方法ではありませんか？ （過度に単純化された方法で）。少し混乱しているように思いますが、MiTM攻撃を防ぐために考えられる唯一の解決策は、TLS/SSLを使用することです。しかし、現在、TLSなしでWebサイトがユーザーを認証する方法は？また、OpenIDは中間者攻撃に対しても同様に脆弱であるように見えますが、それは私が理解していないか、私が見逃しているものでなければなりません。
たとえば、パスワードとチャレンジをハッシュ化してサーバーに送り返します。サーバーはユーザーの保存されたパスワードと同じことを行い、両方の値が同じかどうかを確認します。
このシナリオでは、サーバーはユーザーの完全なパスワードをプレーンテキストまたは暗号化された形式で保存する必要があります。これはセキュリティ上のリスクをもたらします-データベースが危険にさらされると、パスワードが攻撃者に与えられます。パスワードは、レインボーテーブルの攻撃を防ぐために、ランダムな値で「ソルト化」されたハッシュとして保存することをお勧めします。この方法では、サーバーは最初からパスワードを持たないため、誤ってパスワードを漏らすことがありません。
また、OpenIDは中間者攻撃に対しても同様に脆弱であるように見えますが、それは私が理解していないか、私が見逃しているものでなければなりません。
OpenIDは、HTTPS経由でのみ有効です。さもなければ、それは確かに中間の攻撃の男性に対して脆弱です。
しかし、ユーザーCがサーバーへのAの応答を傍受し、それをCであるかのようにサーバーに送信できるとしたら、これはどのようにしてユーザーAをサーバーBに対して認証できますか？次に、サーバーはCにリソースAへのアクセスを許可することを承認します。
この場合も、HTTPSがこれを処理します。クライアントAとサーバーB間の最初のハンドシェイクでは、メッセージは公開/秘密鍵暗号化を使用して暗号化されます。この公開鍵/秘密鍵はサーバーBに保持されているX509証明書に格納されており、クライアントAは、公認の認証局によって署名されていることを確認することにより、公開鍵を検証できます。
サーバーCは、独自の公開鍵と秘密鍵のペアを代用して中間者攻撃を試みる可能性がありますが、クライアントAはサーバーCの証明書が適切に署名されていないことを認識します。
これは、まさにPAKEや [〜＃〜] srp [〜＃〜] などのプロトコルが解決しようとしている問題です。 PAKE/SRPを使用すると、クライアントとサーバーは、クライアントとサーバーの両方が知っているパスワードに基づいて相互に相互認証します。
クライアントは、パスワード（またはパスワードと同等のデータ）をサーバーに送信せずに、パスワードを知っていることをサーバーに示します。さらに、サーバーはパスワード（またはパスワードと同等のデータ）を格納せず、辞書攻撃の影響を受けません。また、盗聴者または中間者は、パスワードを取得するための十分な情報を取得できません。これにより、偽の証明書を使用した中間者攻撃を効果的に防ぎ、「フィッシング」サイトがユーザーのパスワードを盗むのを防ぎます。