1Password のログイン時、マスターパスワードは 1Password のサーバに一度も送信されていません。

少し前まで、私はこれを知りませんでした。パスワードマネージャーなのだから、当然サーバがマスターパスワードを受け取るのだろうと思っていたのです。それで暗号化された金庫を開いていると。しかし違いました。

サーバ側は「あなたが正しいマスターパスワードを知っている」ことだけを確認します。パスワードそのものは受け取りません。金庫の中身も、金庫を開ける鍵も、サーバは知らない。それでもログインは通ります。

この設計を知ったとき、UX の滑らかさとセキュリティの強さが同居する理由がやっと腑に落ちました。この記事では、その中身を「2つの秘密の鍵」と「見せずに証明する認証」という2つの仕組みで解剖します。

使いやすさに違和感を持った瞬間

はじまりは 1Password の使いやすさへの違和感でした。

新しい端末でログインするとき、私はメールアドレスとマスターパスワードを入れます。あとは QR コードを1枚読み込むだけで金庫が復元されます。数秒で終わります。

しかし、これほどスムーズなら疑ったほうがいい。「サーバがマスターパスワードで金庫を復号し、新しい端末に流し込んでいるだけでは？」と。もしそうなら、サーバが侵害された瞬間、世界中のユーザーの金庫が総当たり攻撃の標的になります。

それでも 1Password は 2022 年の LastPass インシデントのような大規模被害を起こしていません。使いやすいのに、なぜ強いのか。この違和感が、公式のセキュリティホワイトペーパーを読み始めた入口でした。

LastPass が破られた2022年、何が起きたか

1Password の話に入る前に、対照として LastPass の 2022 年インシデントを整理します。

2022 年 8 月に LastPass の侵害が公表されました。その後の調査で、同年 8-9 月にかけて攻撃者がバックアップストレージから暗号化された金庫データを持ち出していたことが判明します。11-12 月に顧客への公表が続きました。個々の金庫はマスターパスワードから導出された鍵で暗号化されているため、鍵そのものは盗まれていません。

しかし、金庫のメタデータ (URL など) は暗号化されておらず、最大の問題はここからです。攻撃者はオフラインで、任意のマスターパスワードを試して、正しい鍵が導出できるかを延々と検証できます。

金庫の暗号化には PBKDF2 のような鍵導出関数が使われます。しかしこれは総当たり攻撃を「遅くする」だけで、「不可能にする」わけではありません。ユーザーのマスターパスワードが短ければ、GPU 数枚で数日以内に破れます。そしてパスワード漏洩調査の常連リストを見ると、みなさん想像通り、短いものが並んでいます。

サーバから金庫が盗まれると、多くのパスワードマネージャーに残る砦は「マスターパスワードのエントロピー」だけです。弱いパスワードを付けていた金庫はここで破られます。この構造は多くの製品で再現し得ます。

ここが 1Password と分岐する点でした。1Password は、金庫を守る鍵の一部を「サーバがそもそも知り得ない秘密」で構成するように設計されていました。それが Secret Key です。

秘密1: Secret Keyで+128bitを混ぜる (2SKD)

1Password の中核が Two Secret Key Derivation、通称 2SKD です。

Account Unlock Key (以下 AUK) は、Vault 内の秘密鍵やデータ保護鍵を復号する起点になります。この AUK を、2つの独立した秘密から導出するのが 2SKD です。1つはあなたのマスターパスワード、もう1つが Secret Key です。

Secret Key は 128 bit のランダムな値です。初回サインアップ時に 1Password クライアントが生成します。サーバはこの Secret Key を受け取ることも、生成することもありません。

エントロピーで見る差

現実的なマスターパスワードのエントロピーを見積もってみます。ランダム生成した 12 文字の英数字パスワードで約 71 bit です (log2(62^12))。人間が覚えて運用できる範囲だと、40〜60 bit が現実的な水準でしょう。

ここに Secret Key の 128 bit が加わります。導出関数の入力エントロピーは、実質 200 bit を超えます。

秘密の構成	実効エントロピー	GPUオフライン総当たり
弱いMPのみ	40 bit	数分
強いMPのみ	71 bit	数十年
MP + Secret Key	199 bit	現実的な時間内で不可能

Secret Key が「まとも」に混ざる限り、サーバから金庫が盗まれても、オフライン総当たりは成立しません。攻撃者は Secret Key を知らないので、探索空間が現実的な計算資源では踏破できないほど広がります。理屈のうえでは解けます。ただ、答えが出る頃にはたぶん人類はいません。

派生フローの概観

正確な派生は 2 レーンに分かれます。Master Password 側は PBKDF2-HMAC-SHA256 を 100,000 回、salt はメールアドレス。Secret Key 側は account ID を salt にした HKDF-HMAC-SHA256。両者の出力を XOR して AUK にします。ホワイトペーパーの §3 と §8 に完全な仕様が載っています。

ここで押さえたいのは一点だけです。サーバは Secret Key を知らないので、盗んだデータから AUK を作れません。

そして次の仕組み (SRP-6a) で、この AUK やマスターパスワードを、認証のときにサーバに送らずに済ませます。

秘密2: SRPで「鍵を見せずに開けて見せる」

もう1つの主役が SRP (Secure Remote Password protocol) です。

SRP を一言で言えば「サーバに秘密を送らずに、その秘密を知っていることを証明する」プロトコルです。金庫の例えで書き直すとこうなります。

私が正しい金庫の鍵を持っていることを、鍵そのものをあなたに見せずに証明したい。

日常感覚では奇妙ですが、暗号ではよくある要求です。パスワード認証も本質的にはこれです。SRP はその中でも、サーバに verifier だけを保存する設計をとります。パスワード相当の値そのものは、一度もネットに流しません。

サーバに verifier と salt を保存する

初回サインアップ時、クライアントは 2SKD で作った値から SRP verifier を計算し、サーバに送ります。verifier は一方向関数の出力です。そこから元のマスターパスワードや Secret Key を復元することはできません。

サーバが保持するのは、この verifier と認証用の salt です。加えて暗号化された鍵束や暗号化済みのアイテム本体も保持しています。しかしいずれも、マスターパスワードや Secret Key そのものは含みません。verifier や暗号化済みデータから金庫を開くことはできません。

ログイン時のやり取り

ログインでは、クライアントとサーバが乱数を交換し合いながら、互いに「自分は正しい値を持っている」ことを証明します。

このやり取り全体で、マスターパスワードや Secret Key、AUK に相当する値はネットワークに出ません。中間者が全パケットを傍受しても、そこから鍵を復元できない仕組みです。

3つの守り

SRP-6a のよさをまとめると、こうなります。

サーバ盗難耐性: サーバから verifier だけ盗んでも、逆算でマスターパスワードを引けない
中間者耐性: 通信を傍受してもパスワード相当の値が流れていない
オフライン攻撃耐性: 認証ラウンドの録画からもパスワード試行が事実上できない

普通のパスワード認証は、この3つを何ひとつ満たしません。POST /login で平文の password を送るタイプのことです。TLS で暗号化されていても、サーバはパスワードそのものを一度は受け取ります。1Password ではその「一度」がありません。「たった1回だけでしょ」がセキュリティでは致命傷になる、という話です。

SRP は 1990 年代から知られている古いプロトコルです。ProtonMail や AWS Cognito などでも採用例があります。それでも解説記事が少ないのは、実装が難しくライブラリの品質に依存するためです。

2SKD × SRPが使いやすさを損なわない理由

2SKD で、サーバから金庫が盗まれても総当たりが成立しない状態を作りました。SRP で、マスターパスワードをネットに流さずに認証できるようにしました。ここまで来れば、冒頭の違和感の答えが出ます。

新しい端末で 1Password にサインインするとき、必要なものは3つです。

メールアドレス (誰の verifier を引くか)
Secret Key (2SKD の片方の秘密)
マスターパスワード (もう片方の秘密)

このうち Secret Key は初回サインアップ時にランダム生成された 128 bit です。あなたのデバイスだけに保存されています。新しい端末にはそれをコピーしないといけません。

ここで登場するのが、あの QR コードです。既存の端末で表示した QR コードには Secret Key が含まれています。新しい端末のカメラで読み込むだけで運搬が終わります。手打ちより早く、しかもネットに流さない。

UX の滑らかさは、実は「Secret Key を人間が扱わなくていい形に落とし込むデバイス間搬送」の設計から来ています。認証はサーバに秘密を送らないので速い。Secret Key の運搬は QR で数秒。一度端末に入った Secret Key は、再入力を求められることもほとんどありません。

セキュリティを積み増しても、それを「見えない場所」に隠しきると UX は壊れません。1Password の設計はその実例です。もし QR コードの中身を毎回意識させられていたら、私はたぶん初日で使うのをやめていました。

まとめ

1Password の2つの仕組みは、以下の役割を分担しています。

2SKD: サーバから金庫が盗まれても、Secret Key を知らない攻撃者にはオフライン総当たりが成立しない
SRP-6a: 認証時にマスターパスワード相当の値を一度もサーバに送らない

サーバは金庫の中身も、金庫の鍵も、金庫を開けるための秘密も知らないままで、あなたのログインを検証します。これが「使いやすいのに強い」の正体でした。とか偉そうに書きましたが、私はこれを知るまで数年、何も考えずに使っていました。

パスワードマネージャーを選ぶとき、私はこの2つの観点で他社を眺めるようになりました。金庫が盗まれたとき、あなたのマスターパスワードだけがセキュリティの砦になっていないか。認証時にパスワードそのものがサーバに届いていないか。この2つがどこまで担保されているか (眺めるだけで、乗り換えコストが重いのでまだ動いていません)。

みなさんは日常のツールで、UX とセキュリティの綱引きにどんな解を見たことがありますか。よければコメントで教えてください。

次の疑問

ここまで読むと、こんな疑問が湧きます。「サーバもクライアント同士も相手のマスターパスワードを知らないなら、どうやってチームで同じパスワードを共有できるのか」。答えは、公開鍵暗号を使った Vault Key の配布です。各ユーザーが持つ RSA キーペアと、Vault Key の暗号化配布の話。この続きは別の記事で書きます。

参考

「サーバも自分も過度に信じない」前提でシステムを組み替える発想は、AI 連携プロトコルのセキュリティ設計でも共通です。より深く知りたい方は下記もどうぞ。

MCPセキュリティ実践入門