Passkey Fallback Strategies

この記事では、phishing対策のためにパスキー導入してるRPが、パスキー使えないときにどういうFallback/リカバリ方法が利用できるか考えてみようと思う。

## モチベーション

主要なモチベーションは、もちろん嫌われないパスキーを目指すため。

phishing対策のためにパスキーを使おうとすると、どうしてもphishableな認証要素を排除する必要が出てくる。

しかし現状、「すべてのユーザが常に簡単にパスキーを使える」状況ではない。

そのため、パスキーの利用を強制すると、パスキー使えないユーザが

ログインできなくなったり、機能が使えなくなったりして、

[嫌われるパスキー](https://togetter.com/li/2443524)に、貢献することになる。

ちなみに、嫌われるパスキーの中で頻繁にdisれらているのは、ドコモとメルカリ。

Playstationも、パスキーの利用を強制しているが、それほどディスられてはいない。

この要因の一つは、「パスキー使えない時、どれだけFallback/リカバリできるか？」だと思ってる。

![スクリーンショット 2024-12-27 21.55.52.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/12268/743242b0-3633-2caa-dc72-e023141dc95d.png)

> 表書いていて、思ったが、プレステにおいて、特定機能で強制してないから、普通のユーザがパスキー有効にしなきゃいけない状況にはなくて、プレステの大半のユーザはパスキー使ってないから、文句言われてないだけってことは...ないよな...?

---

ということで、

広く認証およびアカウントリカバリとしてよく使われる方法と、それがパスキー使えなかった時のFallback/リカバリとして適切だろうか、

みたいなことを、つらつらと考えてみようと思う。

## 前提
これは「phishing攻撃に対する対策としてパスキー導入しているRP」に対しての話です。

phishing攻撃を受けてない・受けても気にする必要ない・許容してるRPでは、

パスキー使えなかったら、パスワード+SMS OTPとかにfallbackしとけばOK。嫌われない。


## 結論

とりあえず結論。

* Device flow/CIBA with user_codeとか、Email Magic linkとか、phishing耐性あるわけではないけど、比較的phishing siteが作りにくくなるアプローチを使って、self-serviceなリカバリ方法を準備するのがいいだろう

* push通知を受けるデバイスがない、email address、電話番号が到達不能とか、使えないユーザがいるので、一つだけじゃなくて、いくつかの方法を準備する必要がある

* ただリカバリ方法を増やすこと、それ即ちアタックサーフェースが広がることなので、極端に一つだけ弱くなるようなことがないように、複数の方法を組み合わせていく必要がある

* デジタル認証アプリとか、Digital Identity Walletを使った方法も面白いが、利用可能なユーザ数がまだまだ増えないとは思うから、もうちょっと温めておこう


## 詳細

以下の表は、よく使われる認証やリカバリ方法を、4つの指標に対してどうかを見比べてみたもの。

結論で、Device flow/CIBA with user_codeとか、Email Magic linkとかって出しているのは、

この表において、Criticalな問題(赤色の部分)がないのをピックアップした感じ。

以降、それぞれの手法に対して、思ったことをダラダラと述べていく。

![スクリーンショット 2024-12-28 0.13.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/12268/a4e507e0-e109-3684-613a-98979047d186.png)


##  パスワードやOTP: 🙅‍♀️🙅‍♀️🙅‍♀️

パスキーが使えなくなった時、fallbackとして、パスワードやOTPを使うアプローチ。

当たり前だが、パスワードやOTPは、phishing siteで簡単に窃取されるもの。

攻撃者は、ユーザにパスワードとOTPをphishing siteに入力してもらって、

それを使ってログインして別のパスキー作るでもなんとでもできる。

この状況は、Weakest Linkがphishableなパスワード/OTPなので、

phishing対策としてパスキーを導入してる状態ではない。

phishing攻撃を受けても気にする必要ない・許容してるRPだったら使えるアプローチ。


## Recovery codes: 🙅‍♀️🙅‍♀️🙅‍♀️

事前にリカバリコードを発行しておいて、

パスワードやパスキーを紛失時に、それを入力してリカバリするアプローチ。

これも当たり前だけど、phishing siteでコード入力してしまったら、試合終了。

ただ、多くのパスワードマネージャでは、これに類する方法があるよな？

Recovery codesって名前を使ってるのは、Bitwardenくらいだけど、

1PasswordのEmergency Kitとか、DashlaneのRecovery Keyとかも、実質同じ...だよな。

正直今は、consumer applicationにおいて、3rd party passkey manager使ってるのが、

ごくごく一部の人だけだから、表立って大きなターゲットになってないだけって感じする。


## Federation: 🙆‍♀️

パスキーが使えなくなった時の、fallbackとして、

Google, Apple, Facebook等のsocial loginを利用するパターン。

phishing攻撃に対して強いかどうかは、ID連携しているIdPに依存する。

基本的にRPより強い認証を実施してると期待できるけど、それが保証されるわけでもない。

（大抵、acrとかサポートしてないし）

Social loginと、RPが持つ認証を両方要求してるような場合だと、

両方の会社のcredentialsを、一つのphshing siteで窃取するのは難しいだろう。

それ自体がいいアプローチなのかはちょっと微妙な感じするけど...。

ただし、「将来困らないように、ID連携しておこう」なんてユーザは、いない。

ログインできる手段が増えれば増えるほど、アタックサーフェースも広がるわけで、

それを全力で押したいかと言われると、どうなんだろうな...


## Magic link: 🙆‍♀️

よくアカウントリカバリで使われるような、EmailやSMSに対してリカバリ用のリンク送って、

そこから、パスキーの再登録させるようなアプローチ。

攻撃者としては、そのURLをユーザから共有してもらえたら、それを使って攻撃者のパスキー登録できる状態になる。

が、通常のログインにおいて、URLをフォームに入力するとか、不自然すぎるからなのか、みたことない。

Emailだったら、HTML mailにしたらURLは簡単に取れないし、さらに難しくなるだろね。

もちろん、厳密にphishing耐性があるわけではない。

実際使う時に考慮しなきゃいけないことも、色々ある。

* Email addressや電話番号自体が攻撃者の手にあったらやられちゃうじゃんとか、

* SMS にURL送るってこと自体、phishingぽすぎてやりたくないよな、という話だったり、

* 電話番号はリサイクルされるから、それだけでリカバリ察せることはできないなーとか。

そういう話を考える必要はあるけど、パスワードとかOTPみたいに、根本的にダメって感じではない感じする。

Paypayは、電話番号にmagic link送るのやってるよな。




## Device flow / CIBA with user_code: 🙆‍♀️

ログインを試みると、ユーザがログインしてるアプリとかdeviceにpush通知が送られて、

そこで承認すると、ログインできるようなパターン。

承認と一緒に、ログイン側もしくは通知側出ている番号を入力・選択する場合もある。

この番号の確認がないと、phishing site上で攻撃者がやるべきことは、

「push通知送ったから承認してね」というだけになってしまう。

番号があると、ログインしようとしている攻撃者側で表示されてる番号を、

phishing site経由でユーザに教えてあげる必要が出てくるので、phishing siteが作りにくくなる。

そのためリアルタイミングフィッシング攻撃を想定するなら、これは必須だろう。

通知の中に、ログイン元デバイス、場所、IPアドレスなどが入ってれば、気付ける余地はあるが、

大抵の人、そんなの気にしてないよな。

Docomoはこれをやっている。Playstationは前やってた気がするけど、今見たら無くなってるような..。

なんでなくしたのか、ちょっと聞きたい。


## CS問い合わせ: 🙆‍♀️

パスキー使えなくなったら、CS問い合わせてして、本人確認書類を提出してもらって、

既存のアカウントのIdentityと一致していて、account takeoverの可能性が少ないと判断されたら、

パスキーリカバリさせるようなパターン。

self-serviceで復旧できないため、ユーザのフラストレーションが高く、嫌われるパスキーまっしぐらなアプローチ。

かつ、本人確認書類の提出検証を、単に写真撮って送ってもらうみたいな、

本人確認書類の真正性の検証(validation)も、

本人が提出してきてるかどうかの検証(verification)もできないような方法使ってると、

それほどこのやり方が信頼できるやり方かってのも疑問。

単純に実行するのが手間だから、スケールする攻撃に繋がりにくいというだけの話なんじゃね。

ワ方式で本人確認書類を取得・検証して、

基本4情報(氏名、住所、生年月日、性別)が全て一致してたら、

self-serviceでリカバリさせてもいいのかもしれないねー。

名前とか住所は、変わりうるものだから、変わってたら、人間の判断を仰ぐとかいう感じにしておいてもいいよな。


## 回線認証: 🙆‍♀️🙆‍♀️

選ばれしRP・ユーザのみが利用可能な裏技。

ドコモとかKDDIで回線契約者が利用できる。

phishing耐性あるだろう。

wifiを切り替えなきゃ行けないとかのめんどくささはありしかど。



### 複数のパスキーを登録しておく: 🙆‍♀️🙆‍♀️🙆‍♀️

これは、異なるパスキープロバイダに別の鍵を保存しておくことで、

一つのパスキーを無くしても詰まないようにしておくアプローチ。

syned passkeyが出る前だけど、FIDO Allianceのwhite paperでも言われてた。

https://fidoalliance.org/wp-content/uploads/2020/06/FIDO_White_Paper_Multiple_Authenticators_CDWG.pdf

もちろんこの方法は、phishingに対して強い方法。

ただし、「将来困らないように、2つ鍵を登録しておこう」は、基本誰もやらんだろう。

複数端末持ってない人もいるし。

正直、そういうことするのは、この記事読んでる人くらいじゃね？

Google の Advanced Protection Programっぽい感じで、

「2つ鍵を登録しないとパスキーの利用強制されない」、とかだとユーザが詰むのは回避できるよな。

まぁ、その機能使う人はごく少数だし、サービスとしてはphihsingに困る状態は継続するけど。


## デジタル認証アプリを使ったリカバリ: 🙆‍♀️🙆‍♀️🙆‍♀️

デジ庁が出したデジタル認証アプリってありますよね、あれを使ったリカバリ。

仕組みとしては、Federationと同じだけど、大きな違いが2点。

* マイナンバーカード使って認証してる点と
* 連携する別のモチベーションが作れるところ

マイナンバーカードを使って認証している点から、phishingに対しては強い。

デジタル認証アプリ使うにあたって、デジ庁といろいろやり取りしなきゃ行けなそうなあたり、攻撃者がデジタル認証アプリを使ってパターンは可能性低いだろう。

まぁ、やられたとしても、ちゃんとaudとかちゃんとみてたら防げるし。

そしてもう一つのモチベーションの方、

デジタル認証アプリで、犯罪収益移転防止法のワ方式として認められる本人確認が実施できるので、

サービスで本人確認が必要な場合、

「デジタル認証アプリで本人確認した人は、アカウントリカバリをマイナンバーカードで行える」って、状況を作ることができる。

phishing攻撃の本当に意味で気にしてるPRって概して、

本人確認も厳密にやらなきゃ行けないPRが多いし、

こういう方向性を取りたいと思うところも結構あるんじゃないかな。

どれだけの人が署名用電子証明書のパスワード覚えてるのかは、ちょっと知りたいな...


## Digital Identity Walletを使ったIdentity matchingによるリカバリ: 🙆‍♀️🙆‍♀️

まだ使えないけど、期待したい話として。

Digital Identity Walletが使えるようになって、ちゃんとvalidation/verificationができる形で

本人情報をRPに伝えられるようになったら、

それを使って本人情報共有して、Identity一致してるかどうかを確認してリカバリさせる方向性。

CS問い合わせと同じように、基本4情報が全て一致してたら、self-serviceでリカバリさせて、

名前とか住所が変わってたら、人間の判断を仰ぐとかいう感じかな、結局は。

どれだけ普及するのかなーはあるけど、UX的には絶対マイナンバーカードをスマホにかざすよりもいいし、流行ってほしい。



## Digital Identity Walletを使ったEmail・電話番号に基づくリカバリ: 🙆‍♀️🙆‍♀️🙆‍♀️

まだ使えないし、本当にそういう方向性が実現できるのかはわからんけど、期待したい話として。

Digital Identity Walletで本人情報伝える時に、Platformの情報も共有できるようになる、という噂がある。

Googleのいろんな人がAuthenticate 2024とか、FIDO東京セミナーで言われてた。

文脈としては、「アカウント作成のタイミングでパスキー作ろう」という話だけど、

発表後に聞いてみたら、そういう話のようだった。

* どういう形で共有されるのか (mdocのdocumentの一つとして扱われるのか、全然別フォーマットなのか)、

* どういう情報が共有される可能性があるのか (メールアドレス、名前、プロフィールは確度高いっぽいが、電話番号とかGoogleアカウントのIDとかは今のところ微妙っぽい..)、

* どれほど信頼をおける情報なのか (ユーザが単に自己申告ベースで登録してるものを出すだけなのかどうか)、

とか諸々不明確なことはかなり多い。

でも、その話を聞くと、こういうこと期待しちゃうよね。

* Digital Identity Walletを使って、Magic linkとかOTPに頼らずに、Email・電話番号の所持確認ができる、phishing耐性がある形で...、とか
* Digital Identity Walletから、PlatformのIDが返ることで、本人確認と同時にID連携できるとか(デジタル認証アプリでできてることだけど)、とか...

できたら、すごく面白いだけどなー。

来年にもっと情報出てきて欲しい案件。

---

そんな感じ。

2025年は、嫌われないパスキーを目指していきたいですな。

あと、もっとwalletでなんかやりたい。

恐惶謹言