ユーザー名を平文で送信せずにセキュアリモートパスワードを使用する
SRPプロトコル を使用してキー交換を開始するには、クライアントがユーザー名を送信して、サーバーがソルトとパスワードのベリファイアを検索できるようにします。盗聴者がユーザー名を発見できないようにこれを変更する簡単な方法はありますか？
追加のDiffie-Hellmanで対処できると思いますが、SRPプロトコルは非常に似ているので、オーバーヘッドをあまりかけずにそれをマージする方法があるのではないかと思います。
Diffie-Hellmanはここでは役に立たないでしょう。アクティブな攻撃者は、古典的な [〜＃〜] mitm [〜＃〜] を使用して、DHキーで保護されているはずのデータを確認できます。彼はSRP交換を「外部から」見るだけで、ユーザー名を学習します。
接続ユーザーの非匿名性は Password-Authenticated Key Exchange アルゴリズムのかなり基本的な特性です。このようなプロトコルは、オフラインの辞書攻撃に抵抗します双方がプロトコルの初期段階でパスワード固有のコミットメントを行うためです。
SRPでは、サーバーはランダムにbを選択し、送信B = v + gbクライアントに。偽のサーバーはvを認識していませんが、それを学習したいと考えています。これは、vを認識することで、オフラインの辞書攻撃（つまり、パスワードが一致するまで攻撃者自身のコンピューター上で、相互作用することなくパスワードを「試行」）できるためです。ユーザーまたは実サーバーではもう使用できません。ただし、離散対数の難しさのため、攻撃者はvとbの両方が特定の[〜＃〜] b [と一致します。 〜＃〜]、ただし彼がvとbを選択し、それらの値から[〜＃〜] b [〜＃〜]を計算した場合。ただし、攻撃者は過去を振り返ることはできません。メッセージと次のようなことを考えます：「まあ、私はvの代わりに、私はv 'を使用すべきだったと思います。それがクライアントが理解していたことだからです。」彼がそうした場合、彼は失うbの知識、およびbの知識なしで、彼は後続のDiffie-Hellman交換の「外側」にいます（SRPは、そのコアで、ベルが付いたDiffie-Hellmanです）。 、[〜＃〜] b [〜＃〜]はコミットメントです：サーバーは指定されたpaにをコミットします刀に依存する値v送信時[〜＃〜] b [〜＃〜]、彼が使い続けない限り、プロトコルの残りの部分から有用な情報を取得できないためv。これがPAKEの魔法です。このコミットメントにより、攻撃者はeveryパスワードが推測しているパスワードについて、ユーザーまたは実サーバーまたはその両方と対話する必要があります。これにより、辞書攻撃の効率が大幅に低下します。 PAKEプロトコルのポイント。
サーバーはプロトコルの最初に特定のパスワードに依存する値にコミットする必要があるため（before認証が実際に発生した）、サーバーはどのパスワードについて話しているのかを知っている必要があります。晴れ"。
盗聴者に関してユーザーの匿名性を維持するには、サーバーはまずユーザーに依存しない方法でクライアントによって認証される必要があります。これは基本的な [〜＃〜] tls [〜＃〜] から取得するものです=サーバー証明書を使用したトンネルですが、SRPを使用する場合、証明書の使用を回避するのは正確ではありませんか？また、インターネット関連の設定でも、盗聴者はユーザーIPアドレスを学習します。これは多くの場合、名前とほぼ同じです。
パッシブ盗聴から身を守りたいだけの場合は、クライアントとサーバー間に暗号化された接続を設定し、この暗号化された接続を介してすべてのSRPメッセージを送信するという簡単な方法があります。
実際には、クライアントとサーバー間にSSL接続またはVPNを設定し、すべてをこの暗号化されたトンネルを介して送信するのが実用的なアプローチです。クライアントがサーバーの証明書をチェックしない場合、これはパッシブ盗聴に対しては安全ですが、アクティブな攻撃者（中間者）に対しては安全ではありません。
クライアントがサーバー証明書をチェックする場合、これはアクティブな攻撃者やMITM攻撃に対しても安全です（サーバーの証明書を検証するクライアントの能力まで）。
暗号化、通常はSSLなどのトランスポート暗号化を使用して、コンテンツ（ログイン資格情報も含む）を常に保護できます。
DHまたは同様の何かを使用して独自の暗号ベースをローリングすることは、一般的に悪い考えです。確立されたもの（ここでも、SSLなど）を使用すると、予期しない落とし穴からユーザーを保護できます。たとえば、DHで生成されたキーを使用して対称暗号化を行う場合の問題は、認証なしの暗号化であることです。クライアントにはsomeoneへの安全な接続がありますが、その誰かがサーバーであるのか、それがMITM攻撃者であるのかはわかりません。 SSLの証明書ベースの認証は、その可能性から保護します。
したがって、汎用的に使用するために公的に署名された証明書を使用するか、アプリケーションが唯一のクライアントである場合は独自の署名証明書を生成して、クライアントからサーバーへの暗号化接続を確立します。次に、暗号化されたリンクが確立されたら、ログイン認証情報などを送信します。また、オーバーヘッドが最小限であり、セキュリティの向上が大きいため、その後暗号化された接続を保持することもできます。