Passkeys: 打ち砕かれた夢

 (fy.blackhats.net.au)
7 ポイント 投稿者 GN⁺ 2024-04-27 | 3件のコメント | WhatsAppで共有

Passkeysへの夢が壊れた理由

夢

  • 2019年、著者はRust向けのWebauthnライブラリの開発を開始
  • 当時は、この技術がパスワードを置き換えられるという楽観論があった
    • 2要素認証、パスワードレス認証、ユーザー名レス認証などをサポートできると期待されていた
  • 著者が開発したライブラリは業界に大きな影響を与えた

警告サイン

  • Chromeが市場を支配しているため、Chromeが対応しなければ標準から外される問題がある
    • Authenticator Selection Extensionが代表的な例
  • 米国で開かれる対面会議で主要な決定が行われることも問題
    • 国際的な参加者が排除される状況

下降傾向

  • 2022年、AppleがPasskeysを発表
    • 当初はよく設計されているように見えたが、その後のリーダーの発表によりPasskeyがResident Keyとして定義された
    • これは保存容量の小さいセキュリティキーを排除する結果を招いた
  • その後、Passkeyはユーザーをプラットフォームに囲い込む手段へと変質した

悪化する状況

  • ChromeとSafariはセキュリティキーの代わりにcaBLEの使用を強いる
    • ユーザビリティが非常に低い方式
  • AndroidはPasskey対応Webサイトでセキュリティキーの使用を妨げる
    • 開発者向けサンプルはGoogle Passkeyだけを使うよう誘導している
  • ユーザーはPasskeyの利用に多くの困難を抱えている
    • バグ、複雑な手順、キー紛失などの問題が発生
  • Apple KeychainでPasskeyが削除されることが頻繁に発生

展望

  • 著者は、Passkeyは一般消費者にとって失敗すると予想している
    • 企業の利益追求によってユーザー体験が損なわれているため
  • 著者のパートナーでさえ、パスワード方式のほうがPasskeyより優れていると述べている
  • 企業では依然としてセキュリティキーが必要だが、ユーザビリティの問題は残っている
  • 著者はwebauthn-rsプロジェクトを引き続き保守する予定だが、Passkeyの代わりに別の方法を模索中

GN⁺の見解

  • Passkeyがセキュリティキーを排除し、プラットフォーム依存を深める方向へ進んでいるのは懸念すべき点。ユーザーの選択肢を制限するのは望ましくないように見える。
  • 技術を発展させつつ、ユーザビリティを改善することが必要に思える。過度に複雑になったり、制限的になったりしてはならないだろう。
  • 少数の企業の影響力が大きくなることで、標準化の過程で問題が起きるのも早急に解決すべき課題に見える。より開かれた透明な意思決定の仕組みが整えられるべきだろう。
  • 代案として示されたデバイス証明書やスマートカード方式は興味深い。既存のPasskeyの限界を克服しつつ、ユーザビリティも改善できる方法になり得る。
  • まだ過渡期にあるだけに、今後も継続的な技術発展とユーザーフィードバックの取り込みが行われる必要があるだろう。多様な利害関係者が協力し、より良い認証体系を作っていくことを期待したい。

関連記事

3件のコメント

 
2024-04-28
[このコメントは非表示になっています。]
 
GN⁺ 2024-04-27
Hacker Newsの意見

  • Passkeysに関する最大の問題は、それを提供する企業を信頼できないことだ。セキュリティ上の理由でプラットフォームにロックされているが、プラットフォームの囲い込みと見分けがつきにくいことが多い。AppleデバイスでPasskeyを作成すると、そのデバイスから決して持ち出せず、これを変更する方法もない。これはフィッシングには安全だが、Appleがキーを削除したり、iPhoneを手放したくなったりしたらどうすればいいのかわからない。

  • Passkeysに関する長い議論では、セキュリティにおける「知っているもの」の要素を妙に回避しているように見える。米国では、裁判所や法執行機関がユーザー名、指紋、網膜スキャン、Face IDなどを合法的に取得できるが、脳から何かを取り出す権利はない。Passkeysは「知っているもの」を「持っているもの」に置き換えることを好むが、これはセキュリティ上の悪夢だ。

  • 反対意見: Passkeysは大好きだ。Firefoxブラウザと1Passwordマネージャーを使っていて、iPhoneでは1Password + Firefoxを使っている。passkeys.directoryを見て、GitHub、Google、MicrosoftなどのログインをPasskeysに切り替えた。「Passkeyでログイン」ではなく「Touch IDでログイン」などの用語は混乱を招く。1Passwordがデバイス間でPasskeysを同期してくれる。共有コンピューターでログインが必要な場合は不便かもしれないが、そんなことはそれほど頻繁にはない。

  • Passkeysはまだ明確なメンタルモデルがないので避けている。既存のパスワードマネージャーで生成したランダムなパスワードを使っているため、移行する必要性を感じない。ユーザー名/メールアドレス + パスワードは理解できるが、「アプリ専用パスワード」のつらさを覚えているので、一部のオープンソース/CLIツールがPasskeysとうまく統合できないのではないかと心配で、状況が落ち着くまでは待った方がよさそうだ。

  • Apple Keychainエコシステムに全面的に投資しており、複数のAppleデバイスを持っているので、Passkeysは素晴らしい。開発者として、脆弱なSMS 2FAの限界を毎日経験している。ユーザーは簡単にソーシャルエンジニアリングにだまされて2FAコードを渡してしまう。Passkeysはより安全なソリューションを提供するので、開発者はユーザーがCSに電話してコードを大声で読み上げることを心配しなくてよい。SIMスワップでPasskeyが侵害されることはなく、詐欺師とPasskeyを共有することもできない。

  • 技術者として、Passkeysがどう動作して、なぜ優れていて、正確には何なのかがよくわからない。セキュリティ機能が、ユーザー名とパスワードを覚えて安全な場所に保存するのと同じくらい単純でなければ機能しない。デバイス上のキーについて言及されているが、スマートフォンとPCの両方を使うときにどうアクセスするのか、最初にユーザー名/パスワードが必要なのか、デバイスに差し込むキーが必要なのかが気になる。

  • Usernamelessは最適化しすぎている気がする。ユーザーがログイン時にユーザー名を使うのは合理的で良いことだ。どのユーザー名を使っているかを思い出させてくれる。Usernameless Passkeyを使ってサービスにアクセスしていたユーザーが、何らかの理由でPasskeyを失い、そのサービス用のユーザー名まで忘れてしまって、アカウント復旧プロセスを開始できない状況が起こりうる。

  • Passkeysの技術的な動作方法を知らない人は、次の実装ガイドを参考にするとよい: https://webauthn.guide/ Passkeysへの嫌悪感が理解できない。認証のために公開鍵チャレンジへ移行することは、Webセキュリティにとって大きな前進だ。各ブラウザ/OSは秘密鍵を保護し、バックアップする。キーを失っても、「パスワードを忘れた場合」のフローを使って認証資格情報をリセットできる。

  • Passkeysの利用を検討するには、次の要件が満たされている必要がある:

  1. ソフトウェア内でPasskeyを持てること（セキュリティ上の問題があるとしても）
  2. attestation機能を無効化できること

FirefoxやLinux上のChromeのWebAuthn実装がこれらの要件を満たしているかどうかは確認していない。

  • 2FA分野の進展を追いかけようとしているが、Passkeysがいちばん混乱した。Passkeysが次世代技術だという誇大宣伝はたくさん見たが、実際に何で、どう動くのかという説明は見つけにくかった。セキュリティキーに保存されたキーだと知ってがっかりした。ドメイン名ベースでキーをその場で生成するというアイデアは気に入っている。Passkeysの利点は、Webサイトで使うユーザー名を覚えておく必要がないことだが、ささいな利点だ。

  • ドメイン名ベースでキーをその場で計算・再構成する（FIDO2ベース? WebAuthnベース?）技術の正式名称は何か、という関連質問への回答は https://fy.blackhats.net.au/blog/… で見つけた。その場で再構成されたキーは「non-resident credential」と呼ばれる。