シークレットをオンラインで交換する必要がある場合のTLS-SRPの利点は？
共有秘密をオンラインで確立する必要がある場合、SRPについていくつかの実用的な質問があります。
- HTTPSを使用せずにオンラインで共有シークレットを確立する方法はありますか？
- 共有シークレットを確立するためにHTTPSをすでに使用している場合、なぜTLS-SRPをまったく気にしないのですか？つまり、すでにHTTPSを信頼している場合、TLS-SRPに切り替える利点は何ですか？
- https://security.stackexchange.com/a/2531/5002 「SRPはパスワードを回復不能な方法でサーバーに保存する」と主張しています。パスワードハッシュを格納するデータベースを攻撃するのと同じように、攻撃者がブルートフォース攻撃を使用してユーザーのパスワードを理解するのを防ぐのは何ですか？
SRPは、すでにクライアントとサーバー間で共有シークレットを持っている状況向けです。コンテキストで自然に発生する「ペアリング」手順の一部として（たとえば、Bluetooth周辺機器用にSRPが提案されています。一方のデバイスには画面があり、コードが表示され、もう一方のデバイスにはコードが入力されるキーパッドがあります） 。このような共有シークレットを取得する機会がまったくない「完全にオンライン」の状況では、SRPにはほとんど利点がありません。セキュリティはどこかで開始する必要があります。
SRPでは、サーバーが実際に保存するのは、パスワードの一種のハッシュです。保存された値は、プロトコルで使用できるように何らかの数学的構造も満たさなければならないため、「一種」のみです。その値をすぐにクライアントとして認証するために使用することはできませんが、ハッシュされたパスワードと同様に、ブルートフォースの影響を受けやすくなります。 SRPの魔法は、ネットワーク上のデータパケットを監視するだけでは、パスワードに辞書攻撃を適用するのに十分ではないということです。ただし、サーバーが格納するものはそのような攻撃を許可します（そして、非常に一般的な方法で、これは避けられません）。
TLS/SRP で現在指定されているように、サーバーに格納されている値は次のように計算されます。
x = SHA1(s | SHA1(I | ":" | P)) v = g^x % N
ここで、sはソルト、Iはユーザー名、Pはパスワード、vは保存されているものです（xは保存されていません）。 gおよびNはSRPパラメーター（パブリック）です。攻撃者が値vを取得できる場合は、上記の計算を実行して「パスワードを試す」ことができます。
これはソルトハッシュです（それは良いです）が、非常に高速なハッシュでもあります（それは悪いです）。 SRPは、優れた パスワードハッシュ 関数（bcryptなど）と組み合わせることができますが、次の点に注意してください。
- そのための指定された、または事実上の標準はありません。ただし、クライアントとサーバーの両方が特定の点について合意する必要があります。
- 低速ハッシュを使用する場合、接続を実行するときは、サーバーではなくクライアントで発生する必要があります。したがって、これはクライアントの速度で実行されます。