パスキー登場における脅威の変化を正しく意識しよう

Security FIDO passkey

ritou です。

本日2024/10/15(火)にパスキー関連でこんな記事が出ていました。

www.macotakara.jp

ドラフト仕様として「資格情報交換プロトコル (CXP)」と「資格情報交換フォーマット (CXF)」が公開され、資格情報マネージャー内の資格情報 (パスワード、パスキーなど) を別のプロバイダーに転送するための標準フォーマットを定義します。転送が平文で行われず、デフォルトで安全であることが保証されます。

パスキー登録、利用時にユーザーがパスキープロバイダ(パスキーマネージャー、既存のパスワードマネージャーがパスキー対応した存在)を選択できるような流ればApple, Google, MSといったプラットフォーマーが対応を進めています。そしたら当然インポート/エクスポートも必要ですよねーとなって、それが標準化されていると。ユーザーに管理権を与えるべき、という観点では良い流れでしょう。

一方で、インポート/エクスポートが始まることによる懸念を持つ人が出てきます。

上記投稿ではフィッシングの定義が難しい気がしますがそれは一旦置いておき、開発者や利用者として、パスワードレス、パスキー登場という現状において脅威がどう変化するのかに ついて意識しておく必要があるでしょう。

ある攻撃者の最終的なゴールが 特定ユーザーのログインセッションを得る だった場合、いくつかのアプローチがあります。

パスワード認証で言うと

  1. パスワード自体を盗み、あるいは漏洩したパスワードを用いてログインを試み、ログインセッションを奪う
  2. ログイン処理に中間者として入り、ちょろい二段階認証もろともログインセッションを奪う
  3. ログインセッション自体(発行すみのセッションクッキーやトークン)を奪う

と言うところでした。

1について、パスワードリスト攻撃、パスワードスプレー攻撃に対するパッチとして二段階認証が登場しました。 ただし、フィッシング耐性を持たない認証方式では2に対して無力です。 3はhttps登場まえはわりと意識しておく必要があった気がしますが、現状はサードパーティーCookieまわりの議論はあるもののわりと落ち着いているのかなという印象です。

パスキー登場により、この構図は変わったと捉えるのが良いでしょう。 2について、(一部Hybridの際のQR云々の話はあるものの)公開鍵暗号の署名の仕組みとオリジンのハンドリングで対策できるフィッシング耐性がパスキーの特徴です。 となると、残りの1, 3への脅威を意識する必要があります。

今回のインポート/エクスポート機能の実現は1に関連するものです。パスキー含むクレデンシャルのやり取りを安全に実装することは策定中の仕様で実現できるでしょう。 問題はそれを操作するユーザーの方です。人間が一番脆い。 と言うことで、今後はソーシャルエンジニアリングによる正規の方法でのパスキーの奪取が起こらないように気をつける必要があります。

3についても、攻撃の対象となる可能性は考えられます。ブラウザの進化に合わせ、摩擦を生み出さない程度にBearerからSender-Constrainedにしていく必要がありそうです。

今回は全体の流れでこういう考え方をすべきと言う話を書きましたが、実際にサービスに導入していく際はこれをさらに細かく考えていく必要があります。 セキュリティの人たちとも協力しあって安全な仕組みを作っていきたいところですね。

ではまた。