SRP はログイン交換でパスワードを送らずに済みますが、盗まれた検証子を無害にはしません。
Secure Remote Password、略して SRP は、通常のプロトコル交換でパスワードを送信せずに、クライアントとサーバーがパスワードを使って認証する仕組みです。通常ならログイン時にパスワードを受け取るサーバーに対して、その露出を減らせます。
サーバーからパスワード関連の秘密がすべてなくなるわけではありません。サーバーは検証子を保存し、盗まれた検証子はオフラインでのパスワード推測に使われ得ます。「ゼロ知識ログイン」という主張を評価する際、この区別は不可欠です。
従来のパスワードログインと何が変わるのか
従来の設計では、クライアントは認証された TLS 接続でパスワードを送信します。適切に設計されたサーバーは、適切なソルト付きパスワードハッシュを比較し、認証情報のログ記録を避け、推測に対する保護を適用します。TLS は接続を保護し、パスワードハッシュは保存された認証情報を別の方法で保護します。
SRP はこの交換を変えます。登録時に、システムはソルトと検証子の素材を確立します。ログイン時には、双方が新しいプロトコル値とそれぞれの秘密を使い、共有鍵素材を確立して確認します。クライアントはパスワードを、サーバーは検証子を使用します。正直に動作するクライアントは、パスワードそのものをログインのペイロードとして提出しません。
RFC 2945 の SRP 仕様は、プロトコルの基礎を説明しています。後続のプロファイルや実装では、正確なパラメーターとメッセージ検査をレビューする必要があります。設計を「SRP」と呼ぶだけでは、実装上の選択がすべて健全だとは言えません。
| 質問 | 従来の TLS 経由のパスワードログイン | 正しく実装された SRP 交換 |
|---|---|---|
| ログイン時、アプリサーバーは入力されたパスワードを受け取るか | 通常は受け取る | プロトコル交換の一部としては受け取らない |
| どのような機密認証素材を保存するか | 通常はソルト付きパスワードハッシュ | ソルトとパスワードから導出した検証子 |
| 盗まれたデータベースでオフライン推測が可能か | 保存された素材により可能 | 可能。盗まれた SRP 検証子の素材は推測に使える |
| キーロガーから保護するか | しない | しない |
| メッセージ履歴を自動的に暗号化するか | しない | しない |
盗まれた検証子が依然として重要な理由
RFC 5054 の 3.3 節は、検証子の盗難を明示的に扱っています。検証子により、攻撃者がサーバーになりすまし、辞書攻撃でパスワードを復元できることを説明しています。
重要な違いは、検証子が単なる再利用可能なクライアント用ログイントークンではないという点です。しかし、無害という意味ではありません。攻撃者は、あり得る秘密ごとに離散対数問題を解く代わりに、盗んだ素材に対して候補パスワードを試せます。弱いパスワードや使い回したパスワードは、依然として重大なリスクです。
オンラインのレート制限は稼働中のサービスへの試行を遅くできますが、盗まれたデータベース上で行われる計算には及びません。データベースの保護、慎重なパスワード処理、強力で固有のパスワードは引き続き重要です。
SRP が保護しないもの
侵害された端末： マルウェアはプロトコル開始前にパスワードを取得したり、認証後にセッションを盗んだりできます。
悪意のあるログインページ： パスワードを求めるページ自体が敵対的なら、入力された文字列を別の場所に送れます。ウェブアプリには依然として信頼できる配信経路が必要です。
すべての復元経路： アカウントへのアクセスを認めるメール、SMS、サポートの手順には、それぞれ固有の要件があります。最も強い通常のログイン方式も、弱い代替経路によって損なわれ得ます。
あらゆる能動的ネットワーク攻撃： プロトコルのパラメーター、入力検証、相互確認、それを囲む認証された接続が重要です。「パスワードは決して送られない」という標語で、配備環境に定められた TLS 保護を置き換えてはいけません。
メタデータやチャット暗号化： 認証が答えるのは、セッションを受け入れるべきかどうかです。どの会話記録が存在するか、誰がメッセージ復号鍵を持つかを決めるものではありません。
Livara がログインと識別情報の復元を分ける方法
Livara のセキュリティ概要は、SRP 認証を LVR1 メッセージングプロトコルとは別に説明しています。また、独立したランダムな 256 ビット復元鍵で保護される、バージョン 7 の暗号化された識別情報バックアップも文書化しています。
バックアップはアップロード前に暗号化して封印され、チャット履歴ではなく暗号学的な識別情報を復元します。アカウントのパスワードを知っているだけでは、それらの暗号鍵は復元できません。逆に、サポートが暗号化の秘密を再構成できないという説明から、アカウント管理操作やパスワード変更手順が一切存在しないと結論付けることもできません。
脅威モデルは、端末の侵害と可視の通信メタデータも対象に含めています。SRP を理由に、ユーザーの活動のあらゆる側面についてサービス全体が「ゼロ知識」だと呼び直すべきではありません。
実用的な評価チェックリスト
ユーザーは、強力で固有のパスワードを選び、端末を保護し、復元素材を適切な別の場所に保管し、セッションを失効させる方法を理解してください。SRP を使うと主張しているだけの、信頼できないサイトに秘密を入力してはいけません。
技術レビュー担当者は、正確なプロトコルプロファイル、パスワードから検証子への処理、入力検証、失敗時の処理、登録フロー、リセット設計を求めてください。クライアントとサーバーを一緒にレビューします。ログイン成功のテストだけに頼らず、無効な公開値、リプレイ、中断されたセッションのテストも含めてください。
SRP は認証中のパスワード開示を制限する有用な道具です。パスワードの安全性に関する問題が終わるかのように示すより、検証子の盗難、端末の侵害、復元のリスクと併せて実際の利点を説明するほうが、その価値は明確になります。
