SRP はプロトコル内でパスワードを送りません。しかし、それはパスワードの廃止、フィッシングへの免疫、verifier が無害であることとは異なります。
パスキーと SRP は、異なる二つの認証方式です。パスキーは鍵ペアを使い、パスワードを不要にできます。SRP は依然としてパスワードに基づきますが、プロトコルを正しく実装した場合、パスワードを知っていることを証明するために、そのパスワード自体をサーバーへ送りません。
したがって、「パスワードを送らずにログインする」ことと「パスワードを持たずにログインする」ことは同じではありません。方式の選択は、フィッシングの危険、認証情報の管理、復旧、実装の品質に基づくべきであり、「ゼロ知識」という大まかなラベルに基づくべきではありません。
パスキーは何を変えるのか？
パスキーによる認証では、サービスが公開鍵を保持し、ユーザーは秘密鍵を制御することでログインを承認します。認証情報を該当サービスとオリジンに結び付けることは、この方式のフィッシング耐性における重要な要素です。FIDO によるパスキーの説明。
すべてのパスキーが必ずクラウドで同期されるわけではありません。端末やセキュリティキーに結び付くものもあれば、認証情報の提供者を通じて端末間を移動するものもあります。復旧モデルと同期の保護は、その提供者について確認する必要があります。「クラウド同期」というだけで、企業が鍵を読み取り可能な形で保持しているとは結論できません。
ログイン後のセッションの安全性も別の問題です。パスキーは、端末上のマルウェアや有効なセッションの窃取を自動的に無効化するものではありません。
SRP はサーバーに何を渡すのか？
SRP はパスワード認証鍵交換の一種です。サーバーはパスワード自体の代わりに、ソルトや検証子（verifier）などのデータを保持します。双方はプロトコルのメッセージを交換し、秘密と共有鍵を知っていることを確認します。
ただし、verifier は無害なデータではありません。RFC 5054 の 3.3 節は、検証子を入手した攻撃者が、パスワードを推測する辞書攻撃を実行できると明記しています。したがって、「データベースが盗まれてもオフラインで推測する余地は一切ない」という主張は誤りです。
強いパスワード、サーバーの保護、適切なパラメーター、入力検証、ログイン試行の制御は引き続き必要です。また SRP は、パスワードを入力するページが安全であることを保証しません。悪意のあるコードは、プロトコルが実行される前にパスワードを取得できます。
公平な比較
| 質問 | パスキー | SRP |
|---|---|---|
| ユーザーはサービスのパスワードを覚えるのか？ | 通常は不要。ただし認証情報を制御する必要がある | はい。パスワードを知っていることに依存する |
| サービスはログインのために何を保持するのか？ | 公開鍵と関連情報 | 検証子と関連パラメーター |
| フィッシング耐性はどう得られるのか？ | FIDO の設計で認証情報をサービス／オリジンに結び付ける | プロトコル内でパスワードを送らないだけでは、偽の入力画面を安全にできない |
| クラウドは必須か？ | いいえ。端末に結び付いた選択肢もある | プロトコル自体に第三者の ID 提供者は必須でないが、認証サービスは必要 |
| 復旧はどう行われるのか？ | 認証情報の種類と提供者による | SRP という名称ではなく、アカウントと製品の方針によって決まる |
この表から、あらゆる実装に対する絶対的な順位を付けることはできません。弱い復旧フローは、強いログイン方式の利点を損なう可能性があります。
アカウントへのログインとチャットの鍵はどう関係するのか？
認証は、誰に操作を許すかをサービスに伝えます。メッセージの暗号鍵は、誰が内容を開けるかを決めます。製品が両者を関連付けることはありますが、その関係は文書化されている必要があります。
Livara のセキュリティ文書では、ログイン用の SRP が説明され、暗号化された ID のための v7 復旧パッケージは別に説明されています。このパッケージが復元するのは ID であって、チャット履歴ではありません。そのため、「ログインパスワードが正しい」ことは「すべての鍵と過去のメッセージが戻った」ことを意味しません。
この記事は概念上の比較であり、Livara の全ログイン方式の実地試験でも、製品がある RFC を厳密に実装していることの認証でもありません。
選ぶ際に何を尋ねるべきか？
- 端末を紛失した場合、代わりのログイン手段は何で、誰がそれを管理するのか？
- 復旧方式は主なログイン方式より弱くないか？
- 見覚えのないセッションをどう確認し、無効にするのか？
- ログイン方式の変更で、メッセージの鍵や関連付けられた端末は変わるのか？
- 認証情報の同期に、どのアカウントとどの独立した保護が必要なのか？
まとめ： パスキーを本質的に「クラウドだから危険」、SRP を「ゼロ知識だから侵害されない」と呼ばないでください。各方式の境界と製品の復旧方針こそが、信頼できる比較の土台です。
