概要

• Passkeys に関する批判記事が話題になっているが、内容は事実と異なる部分が多い。
• 一般的な パスキー運用 では「アテステーション（attestation）」は利用されていない。
• アテステーションの仕組みやリスクについての誤解が多い。
• TOTPやパスワードよりも パスキー の方がフィッシング耐性が高い。
• パスキーの利用継続を推奨、現時点で避ける理由はない。

「Passkeys are a trap. Do not use them.」論への反論

• 最近話題になった「Passkeys are a trap. Do not use them.」という記事の主張検証。
• 記事は「アテステーション（attestation）」という仕組みがパスキーの危険性の本質だと主張。
• アテステーションによって、特定の認証ソフトやOSのみ利用可能になり、利用者の自由が奪われるという懸念。
• Netflixのパスワード共有禁止やuBlock Origin排除など、極端な未来像を提示。

実際のパスキー運用

• 一般消費者が使う パスキー は、iCloud KeychainやGoogle Password Manager、1Password、Bitwardenなどで同期保存。
• これらのパスキーは、 ウェブサイトにアテステーション情報を一切送信しない 仕様。
• サイト側がアテステーションを要求しても「none（なし）」が返される。
• もし一般サイトが「アテステーション必須」とした場合、ほぼ全ユーザーがログイン不能になる。
• 実際、消費者向けサイトには「アテステーション要求しない」運用が推奨されている。

アテステーションの誤解

• 記事では「認証ソフト・OS・ファームウェアの証明」と説明されているが、これは事実と異なる。
• WebAuthnのアテステーションは「認証器（authenticator）のメーカー・モデル情報（AAGUID）」のみを証明。
• OSやブラウザ、拡張機能、端末のroot化・jailbreak状態、ファームウェアバージョンなどは一切証明されない。

YubiKey推奨の矛盾

• 記事は「アテステーション回避のためにYubiKeyなどのハードウェアキーを推奨」と主張。
• 実際にはYubiKeyこそ アテステーション証明書 を標準搭載し、企業向けにはアテステーション強制運用も存在。
• セキュリティ強化目的でYubiKeyを推奨するのは正しいが、「アテステーション回避」にはならない。

TOTPの限界とパスキーの優位性

• 記事はTOTP（ワンタイムコード）を安全策として推奨。
• TOTPはパスワード単体より安全だが、「フィッシング耐性」が弱点。
• Evilginxなどのフィッシングツールで、TOTPコードごと中継・盗用される事例が多発。
• パスキーは「ドメイン紐付け」されており、他ドメインで利用不可。コード漏洩や入力ミスも発生しない。
• フィッシング耐性を犠牲にしてTOTPへ戻るのは「悪手」。

パスキー利用の推奨

• サイトでパスキーが利用可能なら、積極的に導入・信頼できるマネージャーで管理推奨。
• 複数プロバイダー間での移行性が心配なら、対応サービスを選択。
• 将来的にアテステーションが一般化する懸念はあるが、現時点でその兆候はない。
• パスキー回避はフィッシングリスクを高めるだけで、現状ユーザー保護には逆効果。

筆者の実績・根拠

• WhyNoPasskeys.comでパスキー対応状況を調査・公開。
• SaaS事業でパスキー実装・独自ライブラリ開発、セキュリティレビュー済み。
• パスキーの制限やアテステーション非利用時の課題も公開済み。
• パスキーを日常的に利用し、「現時点で最良のアカウント保護策」と評価。

まとめ

• パスキー は現状、一般ユーザーにとって安全性・利便性ともに最良の選択肢。
• アテステーションの懸念は現実的には当てはまらず、TOTPへの逆戻りは推奨できない。
• パスキー利用の継続 と、必要に応じた業界へのフィードバックが最善策。