Passkeyには依然として問題がある

 (fy.blackhats.net.au)
7 ポイント 投稿者 GN⁺ 2025-12-19 | 4件のコメント | WhatsAppで共有
  • 2025年の現時点でも、パスキー(Passkey) はセキュリティと利便性をめぐる議論の中で、依然として ユーザー体験とベンダーロックインの問題 を抱えている
  • 新たに導入された FIDO Credential Exchange はプロバイダー間の移行を可能にするが、プラットフォーム間の摩擦と断片化 の問題は依然として残っている
  • Apple, Google, Microsoft などのプラットフォーム管理者による バックアップ不可・ロックアウトのリスク が続いており、ユーザーの選択を制限するUI設計が問題として指摘されている
  • パスキーという概念の難解さ と サービス側の誤解を招くコミュニケーション が、一般ユーザーの信頼を低下させている
  • 重要なアカウントを保護するために、自分で制御可能な Credential Manager と Yubikey のようなハードウェアキー の利用が重要である

TL;DR 要約

  • パスキーには依然として欠陥があり、ユーザーはそれを理解したうえで 自分の条件に合わせて活用 する必要がある
    • プラットフォーム提供者(Apple, Google, Microsoft)の Credential Manager だけを使うと、バックアップ不能およびロックアウトのリスク がある
    • Bitwarden, Vaultwarden などの バックアップ可能な Credential Manager の利用を推奨
    • FIDO Credential Exchange を通じて外部 Credential Manager に定期的に同期する必要がある
    • メールなどの重要アカウントは Yubikey をパスキー保存先として使い、強力なパスワード + TOTP を補助手段として維持する
    • Credential Manager にアクセスできない場合に備え、復旧経路を事前に点検 しておくべきである

過去1年間の変化

  • 主な変化は FIDO Credential Exchange 仕様の導入 である
    • これにより、パスキープロバイダー間で 認証情報の移動 が可能になった
  • しかし、プラットフォーム間の摩擦とエコシステムの分断 は依然として存在する
    • 異なるデバイス間でパスキーが 断片化 する可能性があり、ユーザーはそれを認識しないおそれがある
    • Apple デバイスのパスキーは 非Appleデバイスへ同期不可 である一方、Google・Microsoft は一部で可能
    • Apple ユーザーは より強いロックイン を感じる可能性がある

パスキー概念の難解さ

  • パスワードは「自分が知っているもの」、SMS 2FA は「自分が受け取れるもの」として 直感的に理解できる
  • 一方でパスキーは 目に見えない認証要素 であり、ユーザーが直接確認したり印刷したりすることはできない
  • Credential Manager を信頼するプロセスが必要だが、パスキーはその信頼段階を飛ばしてしまう
  • セキュリティ専門家でさえパスキーの動作原理を混同するほど、理解のハードルが高い

「ソートリーダーシップ」とユーザー教育の問題

  • 一部の業界関係者は「パスワード管理の学習は業界の失敗だ」と主張するが、
    実際には パスキーでも Credential Manager の理解が必須 である
  • パスワード・TOTP を好むユーザーは、傲慢だからではなくユーザビリティの問題 を理由にしている可能性がある
  • パスキーはユーザー教育なしでも機能するという考えは、現実とかけ離れた認識 である
  • ユーザーが十分に理解したうえでなおパスキー以外を選ぶなら、そのユーザーにとってパスキーは失敗している ということだ

依然として続くベンダーロックイン

  • FIDO Credential Exchange が存在していても、実際の利用過程における 摩擦とUIによる誘導設計 が移行コストを高めている
  • Apple のパスキー作成モーダルはデフォルトで Apple Keychain の利用を誘導 しており、
    他の選択肢(セキュリティキー、Android など)は Other Options に隠されている
  • ユーザーの選択は 記憶されず、毎回デフォルトに戻される
  • Google Chrome も同様の構造を持ち、プラットフォームのエコシステム内にとどまるよう誘導 している
  • これは単なる保存場所の問題ではなく、ユーザー体験全体のロックイン につながる

クラウドキーチェーンのデータ消失

  • Apple Keychain でパスキーが消えたり、Android デバイスで作成・利用できない 事例が続いている
  • 一部の事例では デバイス初期化でも復旧不能 で、ユーザーのアカウントアクセスが完全に遮断された
  • こうした問題は パスキーへの信頼低下 につながる

ベンダーによるアカウントロック

  • Apple アカウントのロック事例 では、すべてのパスキーが復旧不能のまま消失した
  • Google, Microsoft でも同様の事例が存在する
  • 単一アカウントへの措置によって、すべての認証情報が破壊されるリスク がある

認証サービスによる誤解を招くコミュニケーション

  • 一部のサービスは「パスキーが顔・指紋データを送信する」と説明している
  • 実際には生体情報がデバイスの外に出ることはないが、
    一般ユーザーはこれを 「顔や指紋がインターネットに送られる」 と誤解する
  • このような説明は パスキーに対する不信感と拒否感 を招く
  • プラットフォーム提供者のUIも、こうした誤解を 解消できていない

ユーザーの選択を制限する認証サービス

  • 一部のウェブサイトは依然として 単一のパスキーしか許可しない、あるいは
    authenticatorAttachment オプションで プラットフォーム依存のパスキーのみを強制 している
  • これは セキュリティキーや非プラットフォーム Credential Manager の利用を阻害 する
  • 一部サイトではログイン時に 事前同意なしで自動的にパスキー登録を試みる など、非倫理的な挙動 も存在する

結論と推奨事項

  • 問題の大半は プラットフォーム提供者中心のパスキー管理構造 から生じている
  • ユーザーは 自分で制御可能な Credential Manager を通じて、
    アカウントロック・データ消失のリスクを減らし、定期バックアップ を行うべきである
  • Yubikey(ファームウェア 5.7 以上) は最大150個のパスキーを保存できる
    • 一部のアカウントでは ソフトウェア Credential Manager の代替 が可能
  • メールアカウントは 復旧経路の中核 であるため、
    ハードウェアキー + 強力なパスワード + TOTP を併用し、オフラインバックアップを維持する必要がある
  • Apple・Google などのプラットフォーム は、ユーザーの選択を記憶し、
    セキュリティキー・他プロバイダーの選択肢をUI上で同等に提供 すべきである
  • 開発者 は WebAuthn API の事前フィルタリングを避け、
    ユーザーへ明確に通知したうえでパスキー登録を進めるべきである
  • 核心原則は ユーザーのコントロール権と同意(consent) を確保することだ

関連記事

4件のコメント

 
roxie 2025-12-19

私はパスキーが好きです、、
 
yeobi222 2025-12-19

セキュリティ体系の構造をユーザーが理解できなければ、不信感を強めるだけでしょう。
使い勝手そのものが良いとも、ちょっと言いにくいです
 
koxel 2025-12-19

Google パスワード マネージャーで一度削除してしまったら全部消えてしまい、再発行してもらってから Bitwarden に移しました…
 
GN⁺ 2025-12-19
Hacker Newsの意見

  • 投稿者は依然として passkey を誤解している。多くの人は passkey を失うと復旧不能だと考えるが、実際にはパスワードを失ったのと同じである。ほとんどのサービスではメールや SMS による パスワード再設定 が可能である。ただし Apple、Google、Facebook のようなアカウントは復旧手順が複雑なので、バックアップコード を印刷して安全に保管すべきである。また、password manager にログインするための最後のパスワードや、YubiKey のような外部手段が必ず必要になる

    • passkey 導入前から Apple と Google のアカウントで ロックアウト問題 があったのか気になる。現在の passkey はユーザーが自分でバックアップしたりエクスポートしたりできず、セキュリティエンジニアが キー複製防止 にばかり集中した結果、数十億人がロックアウトのリスクにさらされている。このアプローチは規制リスクを招く可能性がある
    • passkey のリセット可否は サービス提供者の実装 に依存する。中には電話でしか復旧できないという不満もあった
    • Apple と Google のアカウントは、他の大半のパスワードや passkey を保存しているため、これらのアカウントを失うことははるかに深刻な問題である
    • passkey はデバイスごとに独立して存在し、すべてのデバイスに設定する必要はない。他のデバイスでは単にパスワードでログインすればよい

  • passkey については二つ改善してほしい。

    1. 登録済みデバイスが一つしかないのに、UI が不要な選択肢 を表示すること
    2. 最初から SSH キーのような移植性と柔軟性 を持っていればよかった。今はベンダー依存が強すぎる
    • Mac ではセキュリティキーのボタンを先に押せば、選択ステップをスキップできる
    • オプションを隠すのではなくグレー表示にして、「登録済みのキーなし」と案内すべきである。そうすればユーザーが問題の原因を把握できる
    • passkey システムは フィッシング不可能 を目標に設計されており、ユーザーが認証情報を直接エクスポートできないようになっている。結局、ベンダーロックイン の構造に行き着く。たとえば Safari で passkey を使うには iCloud Keychain が必須で、ローカル専用で使うことはできない
    • 技術に詳しくないユーザーにとっては passkey は良い選択肢かもしれない。ただし リカバリーコード を紙に書いて安全に保管できるよう支援すべきである

  • KeePass 関連の問題を見ると、業界がユーザーの 秘密鍵のエクスポート を妨げようとする圧力を強めているように見える。この流れは懸念される 関連 GitHub issue

    • 私はその issue のコメント投稿者である。暗号化バックアップ をデフォルトで要求するのは、エクスポートを妨げることではなく、むしろユーザーがキーを直接管理できるようにすることだ

  • サービス提供者が passkey の保存方式（ハードウェア/ソフトウェア）を強制したり、Touch ID のような MFA を強制したりする限り、私は依然として パスワード + TOTP の組み合わせを好む

    • (1) はすでに不可能である。サービス側が passkey の保存方式を強制することはできない
    • (2) は MFA ではなく生体確認（liveness check） に近い。単に人間がその場でログインしていることを証明する手順である
    • 緊急時には手動入力方式のバックアップが必要になる。結局はパスワードに近い形へ戻る

  • 「ベンダーがユーザーを締め出せる」 という点のため、passkey は絶対に使わない。特にユーザーが死亡したとき、相続人がアクセスできない問題が大きい

    • 関連事例がある: Apple ID の復旧失敗事例, HN 議論
    • 一部の password manager は オフラインのルート信頼体系 を提供している。たとえば 1Password の Emergency Kit は、印刷された復旧コードを通じて相続人や家族がアクセスできる
    • パスワードであれ passkey であれ、ベンダーのポリシー が同じならアクセス制限も同じである
    • こうした契約を 法的信託（trust） の形に変換できればよいが、企業は嫌がるだろう
    • passkey 登録を強要する ダークパターン UI が本当に腹立たしい。会社アカウントでしか使っていないのに、何度も登録を求められる。すでに SSO と 2FA を使っているのに、なぜさらに passkey まで要求するのか理解できない

  • passkey の UX はひどい。いくつ有効になっているのかも分からず、認証アプリが passkey を忘れてしまうこともある。ただただ混乱する

  • Password + TOTP の組み合わせが依然として最も実用的である。デバイス間の移行も Bitwarden にログインするだけで済む。一方 passkey は、デバイス紛失時の復旧手順 が不明確である。iPhone で設定した passkey が Linux デスクトップでも動く理由すらはっきりしない。単一プラットフォームの利用者にしか有利ではない

    • デバイスを複数登録していたり同期していたりすれば復旧できるが、そうでなければアカウント復旧手順以外に方法はない。結局 パスワードより優れているわけではない

  • 結局 passkey は 過度に複雑な設計 である。ロックインを受け入れれば一部の問題は減るが、新たな制約が生まれる。TOTP が現実的な代替手段 である

    • TOTP は面倒だが ユーザーのコントロール権 がある。そこで自作の LazyOTP Chrome 拡張 により、単一認証として使えるようにしている

  • passkey は 大多数の一般ユーザーにとっては優れたソリューション である。複雑なパスワード管理や使い回しの問題をなくし、ログイン手順も簡素化できる。 技術的に理解している立場から見ても、高速で滑らかなログイン体験 のほうがはるかに良いと感じる

    • しかしデバイスを失ったり壊したりすると、すべてのアカウントへのアクセスが止まる。紙に書いたパスワード にはその問題がない
    • passkey の最大の利点は フィッシング耐性 である。誤ったドメインに認証情報を送信してしまうことがない
    • ただし PC と携帯電話の間の 秘密鍵の同期過程 は不明瞭である。結局 Apple エコシステムに完全に縛られる構造のように見える
    • 実際、複数プラットフォーム間で完全にシームレスに動作する実装はまだ見たことがない

  • 私はあらかじめ パスワードマネージャーと 2FA の体制 を構築していたのに、今は passkey へ移行しろという流れのせいで、そのすべての努力が無意味になったように感じる。先回りして備えた人ほど不利益を受ける技術環境 が嫌いだ