クライアントはSRPを使用してどのように登録しますか？

Question

私が理解していることから、利点の1つまたはSecure Remote Password（SRP）は、認証局に依存する必要がないことです。クライアントが新しいユーザーとして登録する機能を必要とするシナリオでは、これはどのように機能しますか？私は3つのシナリオしか想像できませんが、どれも素晴らしいとは思えません。

1）クライアントは登録時にサーバーにパスワードを送信し、サーバーが将来の認証のためにベリファイアを計算できるようにします。パスワードはネットワーク上で脆弱です。

2）クライアントは検証者をローカルで計算し、ネットワークを介して検証者を送信します。ベリファイアはネットワーク上で脆弱であり、辞書攻撃を受ける可能性があります。

3）クライアントはSSLと認証局を使用して登録します。これにより、CAを必要としないという利点がなくなります。

paj28 · Accepted Answer

（1）が最悪ですが、これらのオプションはどれも素晴らしいものではありません。結論として、SRPは素晴らしいアイデアですが、それを展開する方法を理解するのは困難です。特にブラウザのサポートにはパッチがあります-少数のブラウザ用のベータ品質のプラグイン。

今すぐ実用的な作業現場を作りたい場合は、（3）をご利用ください。

理論的には、匿名のDiffie-Hellmanを使用してSSL経由で（2）を使用できるため、CAはありません。その場合、最初の交換では、誰と話しているのかわかりません。しかし将来的には、少なくとも同じサイトであると確信できます。したがって、最初はサイトを信頼せずにサインアップし、時間をかけて信頼を築き、攻撃者が現在信頼しているサイトになりすますことができないと確信しているかもしれません。

それは信頼とあなたがオンラインでどのように取引するかというより広い問題を引き起こします。「Amazonは信頼できると知っているので、使いたい」というモデルを好む消費者も多く、既存のCAモデルもそれによく似ています。ピアツーピアの非階層的な取り決めに興味がある場合、オンラインでどのように信頼を確立しますか？

あなたの質問はオンライン登録のみを対象としています-対面登録などの別の取り決めがある場合は、より良い選択肢があるかもしれません。

Thomas Pornin · Answer

まず、ブラウザはSRPをサポートしていないため、必然的にカスタムローカルアプリケーションについて話します。

セキュリティのために、ローカルアプリケーションコードが「安全」であることが重要です。ユーザーが最初にアプリケーションを持っていなかったと想定し、次にそれを取得して自分のコンピューターにインストールする必要があります。これは、SRP登録の前に発生する必要があります。それでも、ユーザーは、インストールするアプリケーションコードが本物の非敵対的なものであることを確認する方法を持っている必要があります。たぶん彼らはCDROM/DVDからそれを手に入れました。多分彼らはそれを「安全なチャネル」を通してダウンロードした。多分バイナリは署名されています。攻撃者はそのアプリケーションに自分のコードを挿入したいので、その時点で攻撃者を打ち負かすための何らかのメカニズムが必要です。

アプリケーションコードが安全であると仮定すると、そのアプリケーションコードは、サーバーが所有する公開鍵のコピーを埋め込む可能性があります。例えばサーバーの証明書のコピー。その証明書は、自己署名されているか、カスタムCAによって発行されているか、または何でもかまいません。アプリケーションはサーバーの公開鍵を事前に知っているため、サーバーとの安全なトンネルを確立できます。 SSLを介して、外部CAを使用せずに：アプリケーションは、サーバーで使用される証明書が組み込み証明書とビットごとに同一であることを確認するだけです。その時点で、敵対的な盗聴を恐れることなく、ユーザーが選択したパスワードを送信できます。間違いなく、そのSSLを使い続けて、SRPをまったく実行しないこともできます。

「埋め込み公開鍵」モデルは単純で機能します。つまり、機能しない場合は、SRPを使用しても解決できない大きなセキュリティ問題があることを意味します。

ちなみに、この例は、SRPは非常に巧妙なアルゴリズムですが、カスタムのサーバー固有のアプリケーションコードがクライアント側にインストールされているコンテキストでは必ずしも有用ではないことを示しています。 SRPの真の良さは、クライアントコードがgenericの場合に発生します。は、サイト固有のコードを含まないWebブラウザです。しかし、私たちはまだそこにいません。ブラウザはSRPの実行方法を知りません（当分の間...）。

simbo1905 · Answer

または：

クライアントは、自己署名証明書を使用してTSLを使用してベリファイアを登録します。
クライアントは、サーバーのVanillaRSA公開鍵で暗号化されたベリファイアを登録します。

関連する質問では、これらのオプションについて https://security.stackexchange.com/a/78749/4596 で説明しています。

Webサイトへのパスワード証明としてのSRPのコンテキストでは、理想的には、CA署名付き証明書とHTTPSを使用して、ユーザーが正しいサーバーに登録していることを確認します。ログイン時にHTTPSを使用して、ユーザーIDを保護することもできます。次に、多層防御があります。 CA署名付き証明書を使用したくない場合は、自己署名証明書を使用すると、検証者とユーザー名の傍受を防ぐことができますが、ユーザーは偽のサイトに登録するリスクが高くなります。 TSLだけに依存せず、SRPを両方を使用するのに補完的であると見なす理由はたくさんあります（例： Heartbleed ）が、それは質問のトピックから少し外れています。つまり、パスワードをサーバーのメモリにコピーする必要がない場合は、実際にはコピーしないでください。

「外部の権限は必要ない」という特徴は、RFC 5054のTSLの拡張としてのSRPが採用している角度であり、AFAIKは広く採用されていません。これは、sysadminsとdevopsがTSL/HTTPSと証明書に非常に慣れていて、何か新しいことを試すことに非常に不快であるためかもしれません。要するに、TSLのSRPは、「署名された証明書を取得する」を「検証者を安全に配布する」に置き換えるということです。これは、PKIを意味するので、TLSで標準のCA署名付き証明書を使用して、十分に踏み込んでください。文書化されたセットアップ？署名された証明書のコストは以前は障壁でしたが、私は銀行用の公式のものを法外なコストで購入しましたが、かなり疑わしいCAからわずか25ドルで個人用のものも購入しました。したがって、実際には、SRPの「CAを必要としない」という角度は、その発明で思われたかもしれないほど、今日の採用にとってそれほど説得力のある推進力ではないかもしれません。また、「どちらか/または」の心構えを作成し、人々はデフォルトでboth;を使用する必要があります。 CA TSLを使用して、傍受を防止し、フィッシングやSRPをパスワードの証拠として使用して、サーバーでのパスワードの漏洩を回避し、企業のWebプロキシをスヌーピングから防御します。