1Passwordのサインインでは、アカウントパスワードもSecret Keyもネットワークに流れません。社員の端末は2つの秘密から2つの鍵を作り、1つでデータを開き、もう1つでサーバーとの認証を行います。サーバーに残るのは、パスワードを推測する材料にならない値だけです。この設計を知っておくと、「パスワードのハッシュは保存しているか」「通信を盗聴されたらどうなるか」といった審査の質問に正確に答えられます。このページでは、2つの秘密から2つの鍵を作る仕組み、PBKDF2で推測を遅らせる仕組み、SRPによる認証、端末の追加と通常のロック解除、2要素認証とSSOの位置付けを説明します。
2つの秘密から2つの鍵を作る
社員が持つ秘密は、本人だけが覚えているアカウントパスワードと、端末の中で作られたSecret Keyの2つです。この2つを組み合わせて鍵を作る方式を2SKDと呼びます。作られる鍵は2つで、用途がはっきり分かれています。
| 鍵 | 用途 |
|---|---|
| Account Unlock Key（AUK） | 本人の秘密鍵を復号する。秘密鍵から保管庫の鍵、保管庫の鍵からアイテムへと順に開く |
| 認証用の鍵 | サーバーに本人であることを示す。SRPで使う |
2つの鍵は同じ秘密から作りますが、混ぜ合わせる値（ソルト）がそれぞれ別です。そのため、一方の鍵から他方の鍵は分かりません。鍵導出にはメールアドレスも使われるため、鍵はそのアカウントに固く結びつきます。
2SKDの狙いは、サーバーのデータが丸ごと盗まれても、アカウントパスワードを総当たりで試せないようにすることです。試すにはSecret Keyが要り、Secret Keyはサーバーにありません。Secret Keyの強さと保管場所はアカウントパスワードとSecret Keyで扱います。
PBKDF2で推測を遅らせる
アカウントパスワードは、そのまま鍵にせず、PBKDF2-HMAC-SHA256という計算を650,000回繰り返してから使います。1回の推測ごとに同じ量の計算が要るため、推測の速度が大きく落ちます。
PBKDF2が守るのは、端末のデータを盗まれた場合です。端末にはSecret Keyも保存されているため、端末を丸ごと持ち出されると2SKDの守りは効きません。残る守りはアカウントパスワードの強さと、この計算の遅さだけです。Secret Keyはサーバーが破られた場合に効き、アカウントパスワードは端末が破られた場合に効く、と分けて理解してください。
【注意】 2023年1月27日より前に作られ、それ以降にアカウントパスワードもSecret Keyも変えていないアカウントは、反復回数が現行より少ない値のまま残っています。どちらかを変えると現行の値に上がります。組織を作ったときの所有者のように、長く使っているアカウントほど当てはまりやすいため、導入から年数がたっている組織では所有者と管理者にアカウントパスワードの変更を求めてください。
アカウントパスワードは、前後の空白を除き、Unicodeの正規化をしてから計算に入ります。入力の仕方で文字の内部表現が変わっても、同じパスワードとして扱われます。ただし、見た目が同じでも別の文字（ラテン文字とキリル文字のaなど）は区別されます。日本語を含むパスワードを勧めるときは、どの端末でも同じ文字を入力できるかを確かめてください。
SRPでパスワードを送らずに認証する
サーバーとの認証にはSecure Remote Password（SRP）を使います。SRPは、パスワードそのものを送らずに、正しい秘密を知っていることを互いに示し合う方式です。
サーバーが持つのは検証子だけ
サーバーが持つのは、認証用の鍵から計算した検証子という値です。検証子からアカウントパスワードを逆算することはできず、2SKDでSecret Keyも混ざっているため、総当たりの材料にもなりません。一般的なサービスが保存するパスワードのハッシュとは性質が違います。
通信を二重に暗号化する
SRPのやりとりの結果、セッションごとの暗号鍵が生まれます。1Passwordはこの鍵で、TLSの内側をさらに暗号化します。仮にTLSが破られても、氏名やメールアドレスのような秘密でない情報まで守られます。鍵はセッションごとに変わるため、記録したやりとりを再送してサインインすることもできません。
相手が本物のサーバーかを確かめる
SRPは、アプリがサーバーに本人であることを示すだけでなく、サーバーが正しい検証子を持っていることもアプリに示させます。偽のサーバーは正しい検証子を持たないため、なりすましに気付けます。
端末の追加と通常のロック解除
新しい端末で初めてサインインするときは、メールアドレス、Secret Key、アカウントパスワードを入力します。端末はサーバーからソルトなどの値を受け取り、2つの鍵を両方計算します。認証が通ると、暗号化された本人のキーセットを受け取り、AUKで秘密鍵を取り出します。
2回目以降のロック解除では、端末に必要な値がそろっています。アカウントパスワードを入力するとAUKが計算され、秘密鍵と端末に置かれたデータが開きます。端末の中で完結するため、手元にデータがそろっていればネットワークがなくても開けます。多くのアプリは認証用の鍵もAUKで暗号化して端末に保存しているので、2つの鍵を両方計算し直すのは、初めてのサインインと新しい端末の追加のときだけです。
【運用のポイント】 アカウントパスワードやSecret Keyを変えても、本人のキーセットは入れ替わりません。変わるのはキーセットを包むAUKだけです。古いキーセットと古いパスワードを両方盗まれている疑いがある場合は、復旧の手続きでキーセットを作り直します。手順は復旧の実行手順で扱います。
2要素認証とSSOの位置付け
2要素認証は、新しい端末でのサインインと再承認のときにだけコードを求める仕組みです。データの暗号化には関わりません。アカウントパスワードとSecret Keyを両方盗まれた場合に、新しい端末からのサインインを止める追加の関門として働きます。毎回のロック解除では求められないため、端末に置かれたデータを守るのは引き続きアカウントパスワードです。設定は2要素認証の管理で扱います。
Unlock with SSOを使う社員は、アカウントパスワードとSecret Keyを持ちません。代わりに端末ごとのデバイスキーがあり、IDプロバイダーでの認証が通るとサーバーから暗号化されたクレデンシャルの束を受け取って、デバイスキーでAUKを取り出します。サーバーとの認証は同じくSRPで行います。
仕組みが違うので、守りの前提も変わります。
| 方式 | 端末の中に残るもの | 端末を盗まれたときの守り |
|---|---|---|
| アカウントパスワード | Secret Key | アカウントパスワードの強さ |
| Unlock with SSO（生体認証あり） | デバイスキー（iOS、macOS、Androidではハードウェアで保護） | 端末の生体認証 |
| Unlock with SSO（生体認証なし） | デバイスキー | IDプロバイダーのセッションが残っていれば守りが弱い |
WindowsとLinuxでは、デバイスキーをハードウェアで守れず、軽く難読化してディスクに置きます。マルウェアがデバイスキーとブラウザーに残ったIDプロバイダーのセッションを両方盗むと、1Passwordを開けます。SSOを選ぶ組織では、端末の保護と生体認証の許可を一緒に決めてください。詳しくはUnlock with SSOの仕組みと制約で扱います。