パスキーは罠か — フィッシング耐性とコントロールの間のダイヤル

パスキーへの不安はプロトコルの欠陥なのか、それともそのプロトコルを載せたプラットフォームへの不信なのか?

導入

日本時間10月12日の早朝、Hacker Newsのトップページに「Passkeys are a trap」というタイトルの記事が上がり、1144ポイントを集めた。原文はSubstackのブログNon-Functionalに10月10日付で掲載された「Passkeys are a trap. Do not use them.」で、冒頭で想定読者を「ウェブの非技術系市民」と明言している。結論は単純だ。パスキーを拒否し、パスワードより強いセキュリティが必要ならTOTPを使え、というものである。

この論争は唐突に出てきたものではない。3週間ほど前の9月18日には、ウォーリック大学でコンピュータサイエンスを学ぶEthan Hawksleyの「I don’t like passkeys」が853ポイントを獲得している。二つの記事は結論こそ似て見えるが、根拠はまったく異なる。Hawksleyが語ったのはアカウントのロックアウトと復旧、端末の紛失、可搬性という「いま起きていること」だった。Non-Functionalの記事が語るのは、リモートアテステーション(remote attestation)という「これから入るかもしれないスイッチ」である。

Hacker Newsの反応は大きく割れた。原文の問題意識に共感する側と、フィッシングという言葉がほとんど登場しないパスキー批判は核心を外しているという側だ。本稿では両陣営の主張を事実と解釈に分けて整理し、この論争が実は異なるレイヤー、すなわちWebAuthnというプロトコルとApple・Googleの同期実装を混ぜて語っているという点を指摘する。

「隠れたダイヤル」論の構造

原文の論理は段階的に積み上がる。まず著者は、パスワードが危ういという点には同意する。SolarWindsのサーバーがsolarwinds123というパスワードを使っていた事例や、ハワイ州緊急事態管理局の写真の背景に写り込んだ付箋にパスワードが書かれていた事例を挙げる。次にTOTPを持ち上げる。RFC 6238という公開標準があるため特定のアプリに縛られず、ノートPCでも90年代のゲームボーイでも時刻を数えられる装置ならコードを生成でき、シード(seed)をどこに保管するかもユーザーが決められる、というわけだ。

続いて著者は、「パスキー」という名前の下に実は何種類もの認証情報がまとめられていると主張する。コピー可能か否か、移転可能か否か、ハードウェアバックかソフトウェアバックか、ユーザー存在確認の有無、ユーザー検証の有無、アテステーションの有無。仕様は「標準というより部品カタログのように読める」と書き、FIDO Allianceがこれらすべてを同じ名前で呼んだのは、ユーザーに細部を覗かせないための意図的なものだと見る。

核心は最後の項目にある。WebAuthnには認証器データフラグ(authenticator data flags)があり、サイトはUP(ユーザー存在)、UV(ユーザー検証)、BE(バックアップ可能)などを知ることができる。ソフトウェアはこのフラグを偽って報告できるが、リモートアテステーション付きのパスキーは偽装できない。著者のシナリオはこうだ。現時点ではほとんどのサイトがアテステーションを要求していないが、大多数のユーザーが影響を受けないと判断した時点でサイトがスイッチを入れれば、LineageOSのようなカスタムOSや自作のパスキーマネージャーを使う人はログインできなくなる。著者はさらに踏み込み、情報機関やビッグテックが「承認されていないソフトウェアの実行を阻む」ためにパスキーを使いうると書く。ChromeでuBlock Originのサポートが外された件を例に、リモートアテステーションがあればその方針に従わない別のブラウザまで締め出せると主張する。

興味深いのは脚注である。著者は、アテステーションの表示がATフラグにあるとした初版の説明は誤りだったと訂正し、サイトがユーザーのパスキーのアテステーション対応を事前に照会できるかのような示唆も誤りだったと直している。最後の追記の脚注では、パスキーがドメインに紐づいていて中間者攻撃に強いという点、つまりパスキー最大の長所に「触れていなかった」と自ら書いている。そして、アテステーションの心配なしに高いセキュリティを望むならYubiKeyのようなセキュリティキーを使えと勧める。

反論 ― プロトコルの事実とプラットフォームの事実

Hacker Newsの上位コメントの中で最も技術的な反論はagwaによるものだ。（直接の引用ではなく、コメントの要旨の要約）アテステーションは認証情報の登録時にしか要求できず、ログイン時に遡って要求することはできない。サイトがアテステーションを要求するとブラウザは許可プロンプトを出す。Appleのパスキー実装はアテステーションをサポートしていないので、大多数のユーザーがアテステーション付きパスキーを使うようになるまで待ってからスイッチを入れる、というシナリオは現実味が薄い。ただしagwaはアテステーションがWebAuthn仕様の「汚点」であることには同意し、消費者向けサイトが登録時にアテステーションを要求し始めたら強く批判されるべきで、その時点で推奨を見直してもよいと付け加えている。

lxgrのコメントは原文の分類そのものを突いた。（直接の引用ではなく、コメントの要旨の要約）WebAuthnではユーザー存在確認は常に真でなければならず、「ユーザー非存在のパスキー」というカテゴリは仕様にない。「移転可能か否か」という属性もWebAuthnやFIDOには存在せず、パスワードマネージャー間の移行は実装側の選択であってサイトとは無関係だ。ハードウェアバックかどうか、コピー可能かどうかは、アテステーションなしではサイトが信用できないので、結局アテステーション一つに還元される。そう整理すると、サイトが実質的に強制できるのはユーザー検証を要求するかどうか、すなわちパスキーを1要素として使うか2要素として使うか程度だという。lxgrはWebAuthnにユーザーに敵対的な罠が生まれる余地があることには同意しつつ、批判する側は「認識論のレベルを上げる必要がある」と書いた。

原文の脚注6を見ると、著者自身もユーザー非存在のパスキーを受け付けるサイトを一つも知らないと認めている。lxgrの指摘と著者の脚注は同じ方向を指しているわけだ。

フィッシングの観点からの反論は、より短く断定的だった。tgmaは（直接の引用ではなく、コメントの要旨の要約）パスワードとOTPはフィッシングされうるが、パスキーは署名がドメインに紐づいていて転送できないので、それだけで大多数の消費者にとって価値があると述べ、パスキーについての長文に「phish」という文字列が出てこないなら真剣には受け取れないと付け加えた。zamalekは、TOTPの致命的な欠陥は人間がフィッシングサイトに数字を貼り付けないことに依存している点であり、フィッシングされたTOTPで得たセッションがあれば数秒で送金を何件もできると書いた。

一方で、原文に「真実の核」があると見る人もいる。oefrhaは組織内部のシステムでパスワードを廃止し、パスキーのみに切り替えたパスキー推進派だ。（直接の引用ではなく、コメントの要旨の要約）ところが最近1PasswordがuserVerification: requiredを強制し始めたことで、TouchIDのないデスクトップでは多くのサイトでパスキーを使うたびにログインパスワードを再入力しなければならなくなったという。彼はこの経験で、標準が持つ「追加的な制約のポテンシャル」を実感したと書いた。組織でセキュリティ基準を強制するには良いが、B2C認証技術としてそうした制約が広く普及すれば、ユーザーの自由は大きく損なわれるだろうという判断である。彼は、LLMにGoでパスキー認証を何度か書かせたところ毎回requiredを選んだという観察も添えている。

ここが重要である。原文が警告したのはアテステーションという極端なスイッチだったが、ユーザーが実際に先にぶつかったのは、ユーザー検証というはるかに平凡なダイヤルだった。制約は陰謀ではなくデフォルト値として広がる。

Hawksleyの問いはまだ残っている

アテステーションへの恐れを取り除いても、9月18日の記事が投げかけた問いは消えない。Hawksleyはまず、パスキーがドメインに紐づいているため偽のログイン画面ではフィッシングされず、非対称鍵なのでサーバーが侵害されても復元されないという点を認める。そのうえで、個人にとってより大きなリスクは永久的なアカウントロックアウト、自動化されたアカウント停止、端末の紛失だと言う。ログインフローのフィッシングは消えても、アカウントのセキュリティは依然として最も弱い復旧手段、つまりSMS・メールリンク・秘密の質問によって決まる、ということだ。

彼の具体的な指摘はこうである。ハードウェアキーに入ったパスキーは設計上バックアップできないので、キーを2、3本買ってすべてのサイトにそれぞれ登録しなければならない。ディスカバラブルクレデンシャルにはキー1本あたり25から100程度の上限があり、最上位製品でも300程度だ。Hacker Newsではelricも、パスワードストアに700件以上のエントリがあるのにYubiKeyを8本持ち歩けというのか、と問うている。同期パスキーはAppleまたはGoogleのアカウントに紐づいているため、そのアカウントが自動化されたシステムによって停止されれば、その上に載せたすべてのサードパーティアカウントのパスキーを失う。FIDO Allianceはパスキーのエクスポートと相互運用性の改善に取り組んでいるが、Hawksleyの評価ではまだプロバイダーごとに体験が断片化しており、頼るには早い。BitwardenやKeePassXCのようなサードパーティのマネージャーに保存すると、Android Credential ManagerのようなAPIができたとはいえ、ネイティブアプリでの自動入力は依然として不安定だ。

ここでプロトコルと実装を分けると、構図がはっきりする。フィッシング耐性はWebAuthnプロトコルの性質である。オリジンに紐づいた署名という仕組みがそれを保証し、どのマネージャーに保存しても維持される。一方、ロックアウトと可搬性の問題の大半は、同期実装とアカウント復旧ポリシーの性質だ。パスキーをどのクラウドに置くか、そのクラウドがアカウントを停止したら何が起きるか、別のマネージャーに移せるかは、FIDOの仕様ではなくApple、Google、1Password、Bitwardenが決める。アテステーションはこの二つの間にまたがっている。仕様には存在するが、消費者向けパスキーの大部分を占める同期パスキーの実装では事実上使われていない機能である。

原文はこの三つのレイヤーを一つの「パスキー」として攻撃しながら、皮肉にも自らFIDO Allianceを批判したのと同じ混同、つまり同じ名前の下で別のものを混ぜるという混同を繰り返している。そして、アテステーションが最も確実に付いているハードウェアセキュリティキーを代替案として勧めることで、論理がもつれてしまう。

展望と示唆

この論争から実務的に拾えるものは三つある。

第一に、アテステーションは「いま起きていること」ではなく「監視すべきこと」である。agwaとlxgrの説明が正しければ、消費者向けサイトがアテステーションを強制した瞬間、iOSとAndroidの標準パスキーを使う大多数のユーザーが登録できなくなる。そのコストは大きく、登録時のブラウザプロンプトという目に見えるシグナルもある。したがって合理的な態度はパスキーを避けることではなく、消費者向けサービスの登録フローにアテステーション要求が現れるかどうかを見張ることだ。原文の著者の懸念が間違っているという意味ではない。その懸念が現実化する経路は公開されていて、観測可能だという意味である。

第二に、実際の摩擦はもっと地味なデフォルト値から生じる。oefrhaの1Passwordの事例が示すように、ユーザー検証の要求、プラットフォームのマネージャーへと誘導する「ハッピーパス」、アカウント停止時の復旧不能性といったものが、ユーザーの選択肢を静かに狭めていく。サイトを作る側は、userVerificationを何も考えずにrequiredにするのではなく、パスキーを1要素として使うのか2要素として使うのかを意識的に決めるべきだ。復旧経路がSMSしかないなら、パスキーのフィッシング耐性は半分しか効かない。

第三に、ユーザーにとって最も現実的な答えは、原文とHawksleyの双方が示唆する地点、つまり「自分で選んだマネージャー」にある。Hacker Newsでdavid_shawは（直接の引用ではなく、コメントの要旨の要約）TOTPを擁護すること自体がすでに数字を生成するアプリに依存しているのだから、同じソフトウェアでパスキーを管理すればコントロールは保てると書いた。cyberaxはセルフホストしたVaultwarden上のBitwardenでパスキーをエクスポート・同期していると述べた。skybrianは、パスキーを「ペットではなく家畜」として扱い、アカウントごとに複数のパスキーを複数のマネージャーに置けと勧めた。これはHawksleyの言う可搬性の問題に対する運用上の答えであり、フィッシング耐性を手放さずに済む。

(10月15日追記: セキュリティ研究者のScott Helmeが10月14日付で「Passkeys Are Not a Trap」を公開し、Hacker Newsで670ポイントを獲得した。彼は、ほとんどの人が使う同期パスキーはアテステーションステートメントを返さず、サイトが要求しても返ってくるのはnoneだと書く。さらに、WebAuthnのアテステーションはAAGUIDで識別される認証器のメーカーとモデルをベンダーの証明書チェーンとともに伝えるだけで、OS・ブラウザ・拡張機能・root化の有無・ファームウェアのバージョンについては何も語らないと反論している。YubiKeyこそYubico発行のアテステーション証明書を備えて出荷される機器であり、アテステーションが心配なら原文の推奨はむしろユーザーをアテステーションの側へ押しやる、という指摘も加えた。TOTPについては、Evilginxのようなフィッシングキットがパスワードとコードをリアルタイムで中継してセッションを奪うことを挙げ、「後退」だとした。)

結論

「パスキーは罠か」という問いへの答えは、どのレイヤーを問うかによって変わる。プロトコルとしてのWebAuthnは、ドメインに紐づいた署名によってフィッシングを構造的に防ぐ。これはTOTPには提供できない性質であり、原文の著者も最後の脚注で認めている。アテステーションは仕様に存在する危ういダイヤルであることは確かだが、現在の消費者向けパスキーの主流実装では事実上オフになっており、オンにする瞬間は目に見えるようになっている。

本当の罠は別の場所にある。パスキーを一つのプラットフォームアカウントに集約し、そのアカウントの復旧をSMSに任せ、エクスポートできないマネージャーをデフォルトとして受け入れること。これは仕様の問題ではなく、私たちがどの実装を選ぶかの問題である。

あなたのパスキーはいまどこにあるだろうか。そのマネージャーが明日あなたのアカウントを停止したら、どの経路で戻ってこられるだろうか。その答えを持っているなら、パスキーは罠ではない。持っていないなら、パスワードに戻ることも答えにはならない。

出典: