パスキーの真価：認証の「一番弱い入口」を塞ぐエンジニアの責務

深夜の障害対応で、データベースから認証情報が流出したというアラートを受け取った時の絶望感を知っているエンジニアなら、パスキーの「盗まれても意味がない」というフレーズがどれほど甘美な響きを持つか理解できるはずだ。従来のパスワード認証は、ユーザーとサービスが『同じ秘密』を共有するという、いわば『合鍵をコピーして渡す』ような脆弱な構造の上に成り立っていた。ハッシュ化して保存していても、ソルトが不十分であればレインボーテーブル攻撃の餌食となり、偽サイトに誘導されれば、ユーザー自らが攻撃者にその『秘密』を差し出してしまう。これに対し、パスキーが採用する公開鍵暗号方式は、この構造を根本から覆す。

パスキーの認証プロセスでは、サービス側には『公開鍵』のみが保存され、署名を行うための『秘密鍵』はユーザーのデバイス（Authenticator）から一歩も外に出ない。ログインの際、サービス側はランダムな『Challenge』を生成し、デバイス側が秘密鍵で署名を行う。サービス側が検証するのは『秘密鍵そのもの』ではなく、『正しい秘密鍵を持っていることの証明』である。仮にサービス側のデータベースが完全に流出し、公開鍵がすべて露呈したとしても、攻撃者はその公開鍵から秘密鍵を逆算することは数学的に不可能だ。これが『盗まれても意味がない』の正体である。我々エンジニアは、この『秘密を渡さない』という設計思想こそが、認証におけるパラダイムシフトであることを再認識すべきだ。

さらに、WebAuthnの仕様がこの堅牢性を補完している。認証情報がOriginやRP IDと厳密に結びついているため、フィッシングサイトが本物のドメインを騙って署名を要求しても、ブラウザ側がそれを拒絶する。パスワード認証が『人間の判断』という最も不安定な要素に依存していたのに対し、パスキーは『プロトコルによる強制的な検証』を導入した。これは、デッドロックを回避するためにロックの順序を厳密に定義するような、極めてエンジニアリング的な解決策だと言える。

パスキーを導入する際、多くのエンジニアが混同するのが『同期型』と『デバイス固定型』の境界線だ。同期型パスキーは、iCloudキーチェーンやGoogleパスワードマネージャーなどを介して複数端末で共有される。利便性は極めて高いが、その実体は『パスキープロバイダーのアカウント』という別のレイヤーに依存している。一方、Titan Security KeyやYubiKeyに代表される物理セキュリティキーは、デバイス固定型として機能する。これらはFIDO2対応のセキュアエレメントチップを搭載しており、物理的な『モノ』を所有していること自体が認証の強力な証明となる。

以下の表は、パスキーの保存形態による特性を比較したものだ。この違いを理解せずに導入を進めると、利便性とセキュリティのバランスを大きく崩すことになる。

ここで重要なのは、物理キーを使えば『絶対に乗っ取られない』という幻想を捨てることだ。GoogleのTitan Security Keyのような優れたハードウェアであっても、それは認証の『一要素』に過ぎない。もしアカウントの復旧フローがメールアドレス1つで完結するような脆弱な設計であれば、攻撃者はわざわざ強固な物理キーを突破しようとはせず、復旧プロセスという『裏口』を叩く。我々が設計すべきは、単一の認証手段の強度ではなく、アカウント全体を俯瞰した『攻撃経路の最小化』である。物理キーを導入する際は、必ず予備のキーを用意し、かつ復旧手段自体を多要素認証で保護するという、冗長性と堅牢性を両立させた設計が不可欠だ。

パスキーを導入したからといって、セキュリティ対策が完了したと考えるのは早計だ。むしろ、パスキーという強固な扉を設置したことで、他の『弱い入口』が相対的に目立つようになる。セッションハイジャックはその最たる例だ。パスキーでどれほど厳密に認証しても、発行されたセッションCookieがマルウェアによって盗まれれば、攻撃者は認証プロセスを完全にバイパスして侵入できる。GoogleがChromeで進めている『Device Bound Session Credentials（DBSC）』のような取り組みは、まさにこの『認証後のセッション保護』という、次なる戦場を見据えたものだ。

開発者として我々が明日から取るべき処方箋は明確だ。まず、ログインフォームをパスキー対応させるだけで満足してはならない。メールアドレスの変更、パスキーの追加・削除、アカウント復旧といった『特権的な操作』に対しては、セッションの有効性に関わらず、再認証（Re-authentication）を強制する設計を組み込むべきだ。また、SMS認証のようなレガシーな認証手段を廃止し、不要なフォールバックを徹底的に排除することも重要である。アカウントのセキュリティは、最も強い認証手段ではなく、最も弱い認証手段の強度に依存する。これは、システム全体のパフォーマンスがボトルネックによって決定されるのと全く同じ理屈だ。

最後に、読者であるエンジニア諸君に問いたい。あなたの管理するサービスにおいて、ユーザーが『パスキーを設定した』と満足している裏側で、依然として脆弱なパスワードログインや、メールベースの復旧フローが放置されていないだろうか？『パスキー対応』という看板を掲げることは、単なる機能追加ではなく、アカウントのライフサイクル全体を再設計するという覚悟を意味する。認証という最も基本的かつ重要なコンポーネントにおいて、我々はどこまで『ゼロトラスト』の精神を貫けるのか。その問いに対する答えが、明日からのコードに反映されることを期待している。