パスワードを使い回している自覚はある。それでも「まあ自分は大丈夫だろう」と思いながら、今日もどこかのサービスに8文字のパスワードを打ち込んでいる。そういう人は、案外多いのではないだろうか。
最近、GoogleやApple、主要なECサービスなどで「パスキーでログイン」という選択肢を見かけるようになった。指紋や顔認証でログインできて便利、という説明はよく見る。だが、「それは結局、指紋データがサーバーに送られているだけではないのか」という疑いを、一度は持ったことがあるはずだ。この記事は、その疑いに答えるところから始めたい。
パスワードという「共有された秘密」の限界
パスワード認証の仕組みは単純である。ユーザーとサーバーが同じ文字列を知っていて、ログイン時にそれを照合する。これだけだ。
この単純さが、そのまま弱点になる。サーバー側は文字列そのものではなくハッシュ値を保存しているとはいえ、「ユーザーが入力した値をサーバーに送る」という手順自体は変わらない。送った先が本物のサーバーであれば問題ない。だが、送った先が精巧な偽サイトだったらどうか。ユーザーは疑わず入力し、パスワードはそのまま攻撃者の手に渡る。これがフィッシングである。
サーバー側が漏洩する経路もある。ハッシュ化されていても、弱いアルゴリズムや使い回しがあれば突破される。要するに、パスワードという方式は「秘密の文字列をあちこちに送り、あちこちに保存する」という前提そのものに無理がある。
パスキーは「秘密」を一切送らない
パスキーの核心は、公開鍵暗号方式を使い、秘密鍵をサーバーに一切送らないという設計にある。
登録時、デバイス（スマートフォンやPCの認証チップ）は公開鍵と秘密鍵のペアをその場で生成する。サーバーに送られるのは公開鍵だけだ。秘密鍵は、iPhoneやAndroidの機種であればiCloudキーチェーンやGoogleパスワードマネージャー経由で暗号化された状態のまま複数デバイスに同期されることが多い（synced passkey）。一方、ハードウェアセキュリティキーのような専用デバイスでは、秘密鍵はそのデバイスから物理的に一度も出ない（device-bound passkey）。どちらの方式でも共通しているのは、秘密鍵が平文のままネットワークに送信されることは一度もない、という点である。
ログイン時の流れを見てみる。
指紋や顔認証は、ここでは「本人確認のためにデバイスのロックを解除する手段」でしかない。生体情報がサーバーに送られることは一度もない。デバイスのローカルでの照合が済んだあと、動くのは秘密鍵による署名だけである。
送られるのは、いつも違うチャレンジに対する、いつも違う署名だ。これがフィッシングに効く理由でもある。偽サイトがどれだけ本物そっくりでも、偽サイトのドメインに紐づく形で署名は成立しない。ブラウザとOSが、登録時のドメインと現在アクセスしているドメインを照合し、一致しなければそもそも署名の処理自体が始まらない。ユーザーが「うっかり騙される」余地が、設計の時点で塞がれている。
「盗まれても意味がない」の中身
冒頭の疑いに戻る。サーバー側のデータベースが漏洩したら、パスキーはどうなるのか。
漏れるのは公開鍵だけである。公開鍵は、その名の通り公開して構わない値であり、これだけでログインを偽装することはできない。攻撃者が欲しいのは秘密鍵だが、それはサーバーを一度も経由していない。サーバーへの侵入がどれだけ成功しても、届く先には何もない。
これは「ハッシュ化されたパスワードより安全」という程度の話ではない。攻撃者が奪える対象そのものが違う。パスワード方式では「秘密を守る」ことが対策の中心だったが、パスキーでは「そもそも秘密をサーバー側に置かない」という前提に設計が変わっている。守るものが少ないほど、守り方はシンプルになる。
筆者の考え・所感
正直に言うと、パスキーを最初に触ったときは「結局、機種変更したら詰むのでは」という不安が先に立った。実際に古いスマートフォンから機種変更した際、パスキーが同期されず一部のサービスにログインできなくなり、結局パスワードでの復旧手続きに戻る羽目になったことがある。
この経験から感じたのは、パスキーの安全性そのものより、「秘密鍵をどこまでネットワークの外に置くか」という設計が、可用性とトレードオフになっているという点だ。パスワードは「覚えていればどこでも使える」という乱暴さと引き換えに、どのデバイスからでも復旧できる。パスキーは秘密鍵をサーバーに送らない潔癖さと引き換えに、synced passkeyであればクラウド同期の仕組みに、device-boundであればデバイスの所持そのものに可用性を委ねることになる。この同期基盤やデバイス管理への依存が、実質的にパスキー運用の弱点になっているとも感じている。
とはいえ、フィッシングを設計レベルで無効化できる点は、実務でも大きい。過去に扱った社内システムで、標的型フィッシングによる資格情報の窃取を心配してMFAを重ねていたが、パスキーであればその心配の種類そのものが変わる。守るべきものが「秘密の値」から「デバイスの所持」に移る感覚は、使ってみて初めて腹落ちした。
まとめ
- パスキーは公開鍵暗号方式を使い、秘密鍵を平文のままネットワークに送信しない設計になっている
- サーバーに送られるのはチャレンジへの署名だけで、生体情報もパスワードのような共有された秘密も送られない
- 漏洩時に攻撃者が奪えるのは公開鍵のみであり、パスワード方式とは「守るものの前提」自体が異なる
パスワードが完全に消えるまでには、まだ時間がかかるだろう。それでも、「パスワードを覚えなくていい」という利便性の話としてではなく、「秘密をどこにも置かない」という設計思想の転換として捉えると、パスキーの理解は一段深くなるはずだ。