パスキー（Passkeys）は罠だ。絶対に使ってはいけない。

結論から言おう。パスキーは技術的な罠だ。現時点では利用を推奨しない。セキュリティと利便性のバランスを謳っているが、実際にはプラットフォームの囲い込みや、デバイス紛失時の復旧リスクといった深刻な問題が潜んでいる。安易に導入する前に、その背後に隠れたコストとリスクを再評価すべきだ。

理想を言えば、パスキーは「ペット」ではなく「家畜」のように扱うべき。アカウントごとに一つだけでなく、複数のパスワードマネージャーに保存しておくのがベスト。そうすればコピーできなくても問題ないし、必要なら別のを作ればいいだけだし。

この記事は、パスキーの一般的な形態やバラバラな実装に対して書かれた（かなり長文の）力作だね。読む価値はあるし、興味深く、時に懸念されるようなポイントも突いてる。ただ、結論には同意できないかな。TOTPは柔軟でユーザーがコントロールを握れる優れた技術だけど、Bitwardenやkeepass、1Passwordみたいな柔軟なパスワードマネージャーでパスキーを使えば、結局ユーザーがコントロールできることに変わりはない。それに、ユーザー体験はTOTPコードを入力するより圧倒的に楽だしね。パスキーよりTOTPを推すにしても、結局は認証アプリやパスワードマネージャーのようなアプリケーションに依存してるわけで、パスキーの管理にそれらを使わない理由がないと思う。

タイトルのせいで読む気が失せるっていう話が生産的かどうかは分からないけど、あえて言わせてもらう。ヘッドラインは第一印象として強すぎるからさ。この記事は、すでにパスキーを使っていて気に入っている層をターゲットにしてるの？もしそうなら、スタート地点でマイナスだよ。著者が僕の大好きな、時間と手間を劇的に減らしてくれたパスキーを目の敵にしているように見えるからね。パスキーが完璧だなんて思わない。非技術者にとって使いやすいかといえば、全くそんなことはない。正直、彼らにとっては信じられないほど混乱するものだと思う。でも、僕のワークフローで言えば、ログインが面倒でたまらないパスワード＋2FAの状況よりは、パスキーの方がずっといい。セキュリティに関する議論はとても興味深いし、この記事で初めて知ったことも多かった。結局のところ、ユーザーとしての視点で見れば、大した問題じゃないんだ。アカウントがそれなりに安全なら、僕は使いやすさとワークフローの方がよっぽど気になる。

僕もずっとパスキーの不満を言ってきたけど、テック業界の巨人や技術に詳しい人、一般層までみんなが同じ方向を向いているように見えるのが気味悪くて仕方なかったよ。数ヶ月前のPR攻勢は凄まじかったしね。理論上のパスキーは素晴らしいけど、仕様が持つ能力には不安がある。デフォルト設定は変わるものだし、ひとたび変われば人口の99%はそれに従うことになる。その結果、ハードやソフトが非対応という理由でサービスから締め出されるか、泣く泣く従うかの二択を迫られることになるんだ。それに、もう手遅れかもしれない。Apple、Google、Cloudflareはすでに似たようなゴミを押し付けてきていて、デスクトップを使うためだけにモバイル端末を検証するQRコードをスキャンさせられる機会が増えている。

僕はまだ自発的にパスキーを有効にしていない。理由は単純で、ポータビリティを求めているから。紛失の可能性がある特定の端末に縛られたくないんだ。認証情報をバックアップして金庫に保管したいし、サービスごとに強さをコントロールしたい。スマホのロック解除に使う指紋認証を、パスワードマネージャーの長いパスワードと同じくらい強力だとも思っていない。一度、ベンダーのアプリ内で実装されたパスキーを強制されたことがあった（サードパーティ製マネージャーが使えなかった）。即座にそのアカウントを削除したよ。二度目は、決済画面の途中でパスキー導入を促すポップアップが出た時。すぐに間違いだと気づいたけど、簡単に取り消せなかった。導入のボタンは画面中央の緑のボタン一つだけ。オフにするには設定の奥深くにあるセキュリティオプションまで潜って、何度も確認を求められた。しかも、そのプロセスで他の全デバイスからログアウトさせられたんだ。企業がダークパターンを使って強制しようとし、お金を人質に取っている現状は、パスキーの導入がいかにうまくいっていないかを物語っている証拠だと思う。

注意が必要なのは、アテステーション（証明）が要求できるのはクレデンシャル登録時だけってこと。ログイン時に遡って要求することはできない。それに、サイトがアテステーションを要求すればブラウザは許可を求めるプロンプトを出す。NetflixやTwitterはパスキー登録時にアテステーションを求めて、ユーザーが許可を拒否したら登録を弾いているのか？それはかなり疑わしいね。Appleのパスキー実装はアテステーションをサポートしていないんだから。だから、サイトが大多数のユーザーがアテステーション付きパスキーを使うようになるのを待ってから「スイッチを切り替えて非対応を拒否し始める」という著者のシナリオは、あまり現実的じゃない。アテステーションは確かにWebAuthn仕様の汚点だし、ChromeやFirefoxがサポートしなかった方が良かったとは思う（エンタープライズ管理下は別として）。でも、この記事は仮定に基づいたありそうもないシナリオを提示しているだけ。それがTOTPを推奨する十分な理由にはならない。TOTPはフィッシングに脆弱で、パスキーはそうじゃないんだから。もし一般消費者向けサイトがパスキー登録時にアテステーションを要求し始めたら、大いに批判されるべきだし、その時にパスキー利用の推奨を見直せばいい。それまでは、パスキーを使うななんて言わないでほしい。

結論の後の、最後の脚注を見てほしい。

追記：この記事でパスキーの説得力ある事例を挙げられたと感じている。パスキーの最大のセキュリティ機能の一つにさえ触れていなかったのだが、それは（ほとんどのユースケースで）ドメインに縛られているため、中間者（MITM）攻撃に耐性があるということだ。

「説得力ある事例を挙げた……でも、そもそもパスキー開発の動機となった最も重要なセキュリティ機能については触れなかった」

正直、この記事は説得力なんてないと思う。FIDOアライアンスを悪意があるように仮定している一方で、MITM攻撃の防止がキーデザインの一つだったことを完全に見落としている。FIDOのメンバーは常にアカウント盗難に対処していて、パスキーはその大部分を解決する。アカウント盗難のほとんどはフィッシングやソーシャルエンジニアリングによるものだけど、パスキーは前者を完全に解決し、後者の攻撃対象範囲を減らしてくれるんだ。

全く同意できない。フィッシングは大きな問題だ。「パスワード＋OTP」はフィッシング可能[1]だけど、パスキーは不可能（署名がドメインに縛られていて転送できないから）。それだけで、圧倒的多数の消費者にとってパスキーは価値がある。これは理論上の脅威モデルの話じゃない。どれほど賢い消費者であっても、フィッシングを常にかわし続けるなんて期待できない。一度のミスで終わりなんだよ。もしパスキーのメリットについて長文の記事を書くなら、「phish」という単語が含まれていないと、その主張を真剣に受け取ることはできないな。繰り返すけど、これは理論的な話じゃない。Googleや大手テック企業ではYubiKeyが20年近く使われていて、その効果は十分に研究されている。[1]なぜか業界内で見落とされがちだけど、SIMスワップとかは知っていても、OTPがフィッシング耐性ゼロだってことを理解していない人が多いんだよね。

私はパスキー推進派で、組織の内部システムではパスワードを全廃して発見可能なパスキーに完全に切り替えたよ。だから、あのような攻撃的なタイトルを見ると、残念ながら反射的に身構えてしまうし、読む気も失せる。もう少し冷静なタイトルにしてほしかったね。でも、核心を突いている部分も確実にある。1Passwordが最近「userVerification: required」を強制し始めたせいで、TouchIDのないデスクトップでは、多くのサイトでログイン時にパスワード入力を求められるようになった。15年前に1Passwordを登録したのは、複雑なマスターパスワードと、さらに複雑なログインパスワードの両方を入力するためじゃない。15年間守られてきた「パスワードは一つ」という約束が突然破られた気分だ。この体験から、FIDOアライアンスが持つ強大な力と、パスキー標準が追加の制約を課す可能性について危機感を抱いたのは事実（組織内セキュリティには便利だけど）。ちなみに今は「userVerification: preferred」を使ってるよ。結論として、パスキー技術は組織のセキュリティ標準を強制するには素晴らしいと思うし、自分の組織での選択は支持する。でも、汎用的なB2C認証技術として、今回のような追加の制約が広く普及すれば、ユーザーの自由は深刻に損なわれるだろうね。追記：Opus 5.5に「userVerification」の指定なしでパスキー認証のコードを書かせてみたら、毎回「required」を選んできた。今後こういうケースは増えるだろうね。

TOTPは中間者攻撃に脆弱だけど、パスキーはそうじゃない。それだけでパスキーを支持する十分な理由になるでしょ！