Phishing攻撃への対策としてのパスキー利用

パスキーを使った認証自体には、phishing耐性があります。

しかし、パスキーを導入したサービスにおいてphishing攻撃が起こりうるかどうかは、その導入の仕方に依存します。

この記事では、「パスキーを使ってphishing対策をするためには、サービス側はどのようなことを考えたら良いか？」をつらつらと書いてみようと思います。

※ この記事は、phishing攻撃の対策をガチで考えなきゃいけないサービス向けの記事です。

※ この記事は、いろんな記事（主にritouさんのw）で取り上げられている話題を、「phishing対策するためには」という軸で、差し直したような感じの記事です。

パスキーを使ってphishing対策をするためには?

パスキーのphishing耐性を活かして、サービスのphishing対策をしたい場合、ユーザに 「パスキーの利用を強制する」 必要があります。

phishing攻撃が成立するためには、以下２つのステップが必要です。

• Step1. 被害者が、自分のCredentials（パスワードやOTP等）を、phishing siteに入力する
• Step2. 攻撃者が、取得したCredentialsを使い、本物のサービスにログインする

「パスキーが導入されているが、パスキーの利用は強制されていないサービス」について考えてみましょう。

このサービスでは、ユーザがログインする時にはパスキーを利用することができますが、パスキーが利用できない時も考え、パスワードやOTPを使った別の認証要素でのログインも許しています。

ログインフォームでautofill使ってれば、このサービスでパスキーを登録している多くのユーザは、パスキーでログインするでしょう。

しかし大半のユーザは、サービスがパスキーでのログインを推してくるから使っているだけで、 「phishing siteを自分で見分ける難しさを理解して、phishingの被害に会わないようにするために、パスキーでログインしたい」 と思ってるわけでありません。

つまり、phishing site (ユーザが本物のサービスと思い込んでいる)が、パスワード・OTPの利用を要求してくれば、パスキーでログインできないことに疑問を覚えることはなく、入力するでしょう。

そのため、phishing攻撃が成立ための最初のStepは、サービスがパスキーを導入してたとしても発生します。

そして、パスキーの利用が任意なのであれば、step2も実行可能となり、phishing攻撃が成立することになります。

雰囲気の図

パスキーの利用強制によって発生するUXへの影響

「phishing対策としての強度」と「ユーザへの影響」のトレードオフは存在します。

パスキーの利用を強制することで、こんなようなUXへの影響が考えられます。

• 全てのOS、全てのブラウザでサポートされてるわけではないので、サービスを使えないユーザが多少なりとも出てくる。

• パスキー登録には、端末のscreen lockやiCloud Keychainを有効にする必要があり、それをしてないユーザはによって、よくわからない手間(パスキーの仕組みを知らない人にとって)が発生し、サービス利用の妨げになる。

• パスキーを登録してない端末でも、Cross deviceの利用はできます。しかし現状、UX的に比較的難しいので、やり方がわからず「パスキー使えなくてログインできない」ユーザが増えます。それを解消するためのCSオペレーションコストが増えたり、サービスからユーザの離脱が増えたりします。

• 大半の一般ユーザは、そもそもパスキーって何？状態なので、「パスキー」と言われた時点でユーザが離脱する（と思っているstakeholderもいる）

等...

のように、「phishing対策としてパスキーの利用を強制する」ことは、少なからずサービスのUXに影響してしまいます。

そのため、 「phishing対策としての強度」と「ユーザへの影響」とのトレードオフに対して、各サービスにおいて付き合っていく必要があります。

つまり、phisihngが起きたときの被害と、パスキーを強制することによるUX棄損/問い合わせ対応のコスト等を比較して、どのようなパスキーデプロイメントを選択するのかを考える必要が出てきます。

phishing耐性を考慮したパスキーデプロイメント

ということで、phishing耐性を考慮するときに、何を検討する必要があり、どういうオプションが考えられるのかを整理してみようと思います。

検討事項として以下の３つを取り上げてみます。

• サービスにおいてどのようにパスキーを強制するか？
• サービスにおけるアカウントリカバリをどのように行うか？
• サービスが依存する別のサービスのphishingリスクをどう考えるか？

サービスにおいてどのようにパスキーを強制するか？

これがもっとも直接、「phishing対策としての強度」と「ユーザへの影響」とのトレードオフに影響する部分の話です。

一番ストレートな方法は...、

• #1「ユーザ全員に対して、登録・ログインにおいてパスキーの利用を強制する」
  アカウント登録時にパスキーの登録を同時に行う。
  ログインにはパスキーでの認証が必須となる。
  アカウントリカバリ時には、パスワードの再設定ではなく、パスキーの再設定が行われる。

Phishing攻撃によってユーザや会社に対して大きな影響が出るサービスの場合、かつ、将来的にパスキー導入のハードルが下がった状態においては、こういう方向性もあると思います、が、

しかし、phishing対策のためとはいえ、全ユーザへの影響を避けたいというのが自然な気持ちです。。

そのような場合、以下の２つの方向性が考えられます。

• #2「特定ユーザに対して、パスキーの利用を強制するオプションを提供する」
  アカウント登録においては、パスワードや電話番号を使い作成される。
  アカウントの価値が上がるタイミングで、「パスワードレスオプション」を有効を提案する。
  （アカウント登録時にパスキーを登録・「パスワードレスオプション」有効化を促すのもあり）
  有効後は、ログインにはパスキーのみ利用可能となる。
  登録済みパスキーが利用できない環境では、hybrid transportでログインする。
  アカウントリカバリ時には、パスワードの再設定ではなく、パスキーの再設定が行われる。

• #3「特定機能に対して、パスキーの利用を強制する」
  アカウント登録においては、パスワードや電話番号を使い作成される。
  ユーザが特定の機能を利用したい時には、パスキーでの認証が要求される。
  パスキー未登録である場合は、登録・認証後にその機能が利用可能となる。
  パスキー自体の管理をパスキーの認証で守る必要がある。
  登録済みパスキーが利用できない環境では、hybrid transportで認証する。
  パスキーが利用できない状態になった場合、パスキーの再登録を実行するプロセスが必要。

これらの２つはどちらも、パスキーを強制する範囲を限定することで、ユーザへの影響を抑えようとしている方向性です。

ざっくりと、それぞれの効果と影響を受けるユーザをまとめると、

#2 はパスキー登録率・オプションを有効にしてるユーザ数に応じて、phishing対策としての効果が大きくなっていきます。ただし、パスキーの登録率・オプション有効数を増やすのはなかなか難しいので、中長期的に効果をあげていくのに適した方法と言えるでしょう。

一方、#3 は、特定の機能においてパスキーの利用を強制することになるので、少なくともその機能をすでに利用しているユーザは、phishingから守ることができます。ただし、特定機能しか守っておらず、アカウントそのものが乗っ取られる状態は変わらないので、その後の攻撃手法の変化に対して別の対策を打つ必要が出てきます。

#2, #3は、どちらも、部分的にphishing攻撃に遭う可能性が残ります。

そのため、「オプションが有効にされるユーザ数を増やす」、「特定条件でオプションの有効化を強制する」、「パスキーを強制する機能を増やす」、「パスキー登録率をあげる」といった対策を、継続的に行う必要があります。

「パスキー登録してないユーザを守るための別の対策を打つ」という方向性もなくはないと思いますが、phishing耐性ある方法にはならないだろうし、パスキー全推ししていく方がいいんじゃいかな...。

長期的に、パスキーがどれだけ世の中に浸透するかによっては、「ユーザ全員に対して、登録・ログインにおいてパスキーの利用を強制する」方向性を検討することも必要が出てくるかもしれません。

サービスにおけるアカウントリカバリをどのように行うか？

前述した３つのパスキー強制方法どれにおいても、パスキーが利用不可能な状態になった時の回復方法（アカウントリカバリ）を考えておく必要があります。

アカウントリカバリは、結局のところ、 アカウントにログインするため別の認証方法を準備する ということなので、

たとえば「phishing対策のために、パスキーの利用を強制します。ただし、電話番号の所有確認によって、パスキー再設定が可能です」という状態は、SMS OTPでログインできるようにしている（パスキーの強制をしていない）のと同じ状態になります。

一方で、アカウントリカバリは、ログインやログイン後の追加認証ほど、使用頻度が高いものではなく、ユーザの認識としても、多少手間があり時間がかかる状態でも許容されやすいです（ない方がいいけど）

そのため、パスキーでphishing対策したいサービスでは、 「手間や時間はかかるがphishingに対して比較的強い方法」 をアカウントリカバリとして採用することになります。

そのような方法として、以下の２つの方向性が考えられます。（最初のやつほんとか？）

• #1 アカウントに登録されてるemail addressおよび電話番号の所有確認
  パスワード/パスキーを無くした方はこちら のリンクをふむ
  自分のemail addressや電話番号、アカウント名等、アカウントを特定する情報を入力する
  アカウントに登録されたEmail addressにパスキーリセットリンクが送られる
  （SMS OTPでの認証が要求される）
  ユーザが新しいパスキーを登録する

• #2 アカウントに登録されてる本人情報確認
  CS問い合わせして、本人確認書類を提出する
  CS側で本人確認が取れたら、パスキーの再設定ができるようにアカウントの状態を変える
  ユーザが新しいパスキーを登録する

どの方法が採用できるかは、サービスの内容に強く依存します。

もし、サービスが提供している機能の性質として、もともと本人確認情報や電話番号を要求しているサービスであれば、どの方法を選択するかは、純粋にアカウントリカバリの強度とUXの問題として捉えられます。

しかし、サービスがemail addresssしか持っていない場合、Email addressにパスキーリセットリンクが送る以外にやりようがない。。

また、どの方法も完全にphishing耐性がある状態ではないので、一番良いのは、「複数のパスキーを登録させる」、「Social Loginの利用を促す」など、アカウントリカバリに陥らない状況にユーザを誘導することだとは思います。

サービスが依存する別のサービスのphishingリスクをどう考えるか？

以上で、サービスを利用するときにパスキーの利用が強制されている状況が作られたとします。

その後に、気になってくるのは、自分のサービスではなく、依存する外部サービスのアカウントがphishingでやられるパターンです。

例えば、

• メールサーバのアカウント
  これは、アカウントリカバリをemail addressだけでやっているパターンの場合問題になります。アカウントリカバリは、結局のところ、アカウントにログインするため別の認証方法を準備することなので、この場合メールサーバのアカウントの認証に依存する形になります。

• Social loginに利用しているアカウント
  アカウントリカバリが必要ない状態にするための一つの方法として「Social Loginの利用を促す」と書きましたが、それをやればもちろん、Social Loginのアカウントで利用している認証に依存する形になります。

• Synced passkey providerのアカウント
  これは攻撃者に対してpasskeyが共有されるリスクです。Synced passkeyを使っている場合、passkey provdierを介して、複数デバイスに共有されます。もし攻撃者が被害者のpasskey providerのアカウントをphishing等で乗っ取った場合、攻撃者のデバイスにpasskeyが共有される可能性があります。この場合、いくらサービスがpasskeyの利用を強制していたとしても、攻撃者にサービスを利用されてしまいます。

どの場合に対しても共通して行える対策としは、 サービスが自分たちで管理している認証要素での認証を要求すること です。

例えば、SMS OTPやTOTP等。。

ただしこれは、ユーザの手間を増やすものなので、アカウントリカバリにおいては許容されるかもしれませんが、ログインや追加認証といった利用頻度が比較的高くなる認証においては、避けた方が良さそうに思います。

他に「synced passkey providerのアカウント」のリスクに対しては、device-boundだけ利用できるようにするとか、「Social login」に対しては、id_tokenのamrを検証して、phishing耐性のある認証要素でログインされた時のみ許可する、といった方法が考えられますが、どちらも、全てのplatform側で提供されているような機能ではないので、適用範囲は限られるというのが現状です。

まとめ

phishing対策としてパスキーを導入するための検討事項として、主に以下の３つを書いてみました。

• サービスによって許容可能な範囲でパスキーの利用を強制する。

• サービスにおけるアカウントリカバリの方法として、「手間と時間はかかるがphishingに対して比較的強い方法」を採用する

• サービスが依存する別のサービスのphishingリスクに対応する必要があるなら、自分たちで管理している認証要素での認証を要求する

これらは独立したものではなく、整合性が取れた状態にする必要があります。

例えば、「device-bound passkeyしか許してないのに、アカウントリカバリがemail addressにパスキーリセットリンク送る方式になってる」状態では、一番弱いemail addressの認証が狙われるので、ユーザにdevice-bound passkeyを強いているコストに見合わないセキュリティレベルになっています。

そのような状態を避けるために、サービスが提供している機能や、許容可能なリスクを根拠にして、整合性のとれた選択をする必要があります。

おまけ: この世界からphishing siteが撲滅された日

この世界からphishing siteが撲滅された日がやってきたとして、どうやって撲滅されたんだろう....

いくつか想像できる可能性と、どうのようにその状況に至るかを考えてみよっかな

パスワードが撲滅される

サービスにおいてパスワードを使うこと自体が稀になり、原理的にphisihingできなくなることで、phishing siteが撲滅される。この状態になるためには、どのサービスでもパスキーの導入・強制できるようにするために、誰でもどんな環境でも簡単にパスキー登録・利用できるようになることが必要になると思う。そのために、例えば、

• パスキーが使えないOS・ブラウザがなくなる
• hybrid transportが使いやすくなる
• screeen-lock, iCloud keychainが有効ではない時のUXが簡単になる
• ClientおよびServer側実装において、パスキーの導入が簡単になる

というような状況が必要なんじゃないかなと思う。

全E-Commerce・金融系サービスにおいてパスキーが必須化される

phishingの攻撃対象となりやすいE-Commerce・金融系サービスにおいてパスキーが利用必須となることで、攻撃者側のphishingによるマネタイズが難しくなり、phishing siteが撲滅される。E-Commerceにおいては、phishing対策をガッツリやってるところ(例えばFIDO UAFやってますみたいな)のは多くはないと思うので、どのように対策するかを示すのがたぶん重要。一方、金融系のサービスにおいては、すでにphishingを意識しているところも多いので、依存するサービスのphishingリスクを潰すほうが、この状況を作るのに貢献するんじゃないかと思った。例えば、

• サービスにおけるphishing対策のためのパスキー導入方法が明確になる。
• synced passkeyを安全に使う方法が確立させる
• device-boundの利用が選択肢に挙げられるようになる。

とか。

全ユーザが自分自身よりパスワードマネージャーに信頼をおくようになる

ユーザへの啓蒙が進み、誰もパスワードをphishing siteに入力しなくなることで、phishing siteが撲滅される（きつそうw）。この状態になるためには、phishing対策として、個人が行うべき行動の認識がアップデートされる必要があると思う。

• 「phishing siteを判別することは無理、誰でもphishingの被害に遭う」という認識
• 「自分の認知能力よりもパスワードマネージャに信頼を置くべき」という認識

現状よく言われる「正規のURLか確認する」、「パスワードを長くする」、「パスワードの使い回しを控える」とかは、もちろん間違ってるわけではないが、人間に求めるのはきつい。。なので、「パスワードを自分で作らない、パスワードマネージャ使う」、「パスワードを自分で入力しない、パスワードマネージャ使う」、「パスワード使わない、パスキー使う」という方向に啓蒙活動がシフトするといいんじゃないかと思う。。個人の意見です。

---

まぁ、きっと、どれか一つがガッツリ進むというわけではなく、それぞれがちょっとづつ進んで、いつの間にかホットな攻撃方法がphishingから別の何かに変わってるという感じなんだろうなー。終わり。