パスワードを減らすはずの passkeys（パスキー）が、最近は各社のログイン画面でしつこいほど勧められています。便利そうに見える一方で、実際には「もう戻れない」「消せない」「壊れたら詰む」といった不安もある。今回取り上げる記事は、その違和感を真正面から言語化したものです。著者は、パスキー自体を否定しているわけではありません。むしろ技術としては優秀だと認めたうえで、個人のセキュリティ運用にはまだ早いのではないか、と述べています。
Ethan Hawksley は、ここ数年のテック業界が passkeys を「ログインの最終解」として押し出してきたことに触れます。Google は設定名を “Skip password when possible” とし、Microsoft はアカウントを passwordless にするよう勧めるなど、ユーザーが意識しなくてもパスキーへ誘導される場面が増えている、と書いています。
彼の前提ははっきりしています。パスキーは技術としてはすばらしい。作成したサイトにひもづくため、偽のログイン画面で盗まれる phishing に強いし、サーバー側の漏えいが起きても、パスキーそのものを復元されにくい。だから企業環境には向いている。しかし個人にとっての主なリスクは別にある。著者は、パスキーを使うと man-in-the-middle 攻撃への防御は強くなるが、その代わりに「アカウントを失って二度と戻れない」危険が高まると見る。
その理由として挙げられているのが、ロックアウト、アカウント停止、端末紛失だ。標準のログイン経路での phishing は減っても、結局は復旧手段が弱点になる。SMS、メールのリンク、秘密の質問のような recovery method が残っていれば、アカウントの安全性はそこに引っ張られる。逆にそれらを切ってしまうと、今度は完全に締め出される可能性が残る。著者は、パスキーが「安全になった気分」を与えるだけで、日常の運用では別の場所に危険が移ると警戒している。
Hardware key についても、著者は扱いにくさを指摘する。パスキーは hardware key に“バックアップ”として複製できず、追加か削除しかできない。つまり、1本で済ませるのではなく 2〜3 本買って、各サイトごとにすべて登録する必要がある。これでは費用がかかるし、アカウント数が増えるほど現実的でなくなる。さらに discoverable credentials は便利な反面、1本の hardware key あたり 25〜100 アカウント、上位機種でも 300 までという制限がある。上限を超えれば、アカウントを消すか、追加のキーを買うしかない。
同期型の passkeys も、著者には不安材料だ。Apple と Google は、利用者のアイデンティティを自社の OS とアカウントに結びつけたい。端末上での“正しい”流れは、Apple または Google のアカウントにぶら下がった同期管理を使うことになる。だが、もし自動判定でそのアカウントが ban されたら、第三者サービスで使っていた passkeys までまとめて失う。FIDO alliance は export の改善を進めているものの、現時点では断片的で、提供元ごとに挙動も不揃いだ。著者は、これは今すぐ頼るには未成熟だと見る。対して password は、いざとなれば文字列として手で持ち出せる。そこが違う。
さらに、Bitwarden や KeePassXC のような password manager に passkeys を置く第三者管理についても、著者は「プラットフォームと戦うことになる」と表現する。Android の Credential Manager のような API は出てきたが、ブラウザ外や native app での autofill はまだ安定しない。パスワードの自動入力には何年もかけて洗練された UX があるのに、passkeys はまだそこに届いていないというのが彼の見立てだ。
最後に、他人の端末でログインする場面を挙げる。自分の端末なら passkeys は理想的だが、同僚の PC では話が違う。hardware key を挿したくてもポートが空いているとは限らない。同期型を使えば入れるが、その端末が他の passkeys を漏らさないと信じる必要がある。QR コードを読み取り Bluetooth で接続する “Hybrid Transport” もあるが、現実には接続失敗や Bluetooth 非対応がつきまとう。著者の結論は、企業では有効でも、個人向けのエコシステムとしてはまだ熟していない、というものだ。
この記事で面白いのは、著者が passkeys の弱点を「ハッキングされやすいかどうか」だけで測っていない点だと思う。セキュリティの議論では、phishing に強い、漏えいに強い、という分かりやすい長所が先に語られがちだ。だが、普通の利用者にとって本当に痛いのは、侵入されることより「入れなくなる」ことかもしれない。著者はそこを見ている。これはかなり実務的な視点だ。
特に引っかかるのは、passkeys が「弱いパスワードを捨てる技術」から、「アカウント全体の主導権をどこに置くか」という話へ変質していることだ。同期型 passkeys を Apple や Google に預けると、便利さは増す一方で、復旧の裁量までプラットフォームに寄る。ここは単なる認証方式の違いではない。誰が最終的に鍵を握るのか、という権力の問題だと思う。個人は OS やクラウドの都合に従うしかない場面が増える。
もうひとつ重要なのは、著者が hardware key を「安全だが高くつく現実解」として見ていることだ。複数本を買い、各サービスに全部登録し、上限管理までするのは、セキュリティに詳しい人ならまだしも、一般ユーザーには重い。しかも 25〜100 アカウント、上位機種でも 300 という上限は、サービス数が増えた現代では意外とすぐ届く。ここはスペック表では見えない不便さで、実際の運用コストとして効いてくる。
ただし、著者の見方をそのまま一般化しすぎるのも危険だと思う。再利用パスワードを使い回していた人にとっては、passkeys は確かに大きな改善だ。被害の種類を減らす効果は本物で、特に phishing の標的になりやすい人には意味がある。つまり「passkeys はダメ」ではない。どの利用者の、どの痛みを減らし、どの痛みを増やすのかを見ないと判断を誤る。
著者は、個人には password manager に保存したランダムなパスワードと、独立した TOTP app の組み合わせの方がよいと書いています。ここで大事なのは、完璧な安全性ではなく、ユーザーが自分でコントロールできることです。パスワードは平文の文字列として持ち運べるし、管理ソフトを変えても運用を組み替えやすい。TOTP も phishing に強くはないが、少なくとも recovery の複雑さは passkeys ほどではない。著者は、現時点ではこの柔軟さの方が日常には向いていると見ています。
私はこの議論は、パスキーそのものより「復旧設計」が未成熟であることを突いているように感じる。認証方式の改良は目立つが、実際には失くしたとき、止められたとき、他人の端末を使うとき、古い端末を手放すときの手順が整っていないと、日々の安心にはつながらない。便利な鍵を配る前に、戻る道をどう確保するか。そこが先だと思う。
一方で、この記事は今の混乱をそのまま永続化すると読まれるべきではない。FIDO alliance が export の改善を進めているように、エコシステムは動いている。第三者 password manager との連携も、まだ不完全とはいえ前進はしている。だから著者の「まだ早い」は、永遠の否定ではなく、現状への保留だと受け取るのが妥当だろう。少なくとも今は、passkeys を使うなら、バックアップ、復旧、複数端末、アカウント停止時の逃げ道まで含めて考えるべきだ。便利さだけで移ると、思った以上に身動きが取れなくなる。
