ritouです。
最近何度かパスキー関連の記事を書いていて、こんなコメントをいただくことが増えてきました。
”もちろんパスキーでも詰んでしまうことはあり得るのですが” そこだよな
”パスキーでも詰んでしまうことはあり得る“話にならん、何言ってんだ？リカバリ方法のないそんなもん使おうと思う訳あらへん。
別件ではパスワード認証が詰まないと書かれているのも見かけましたので、一回整理しておきましょう。
「どんな認証方式でも、詰む」
パスワード、メールやSMS OTP、メールで送られるマジックリンク、認証用アプリ、TOTP、生体認証、パスキー...全ての認証方式で「詰む」状況というのはあり得ます。
- 知識情報 : 忘れる
- 所持情報 : デバイスや環境をなくす、一時的に利用できない
- 生体情報 : 関連する器官の欠損、怪我など
もちろん、その頻度や条件が異なります。
FIDO認証からパスキーに変わった部分でも、あまりにも「詰む」可能性が大きいために実用的ではないねとなっていたところをパスワードマネージャーの同期を利用して改善しようという流れになったわけで、そのパスワードマネージャーにアクセスできなくなったり、同期している端末全てにアクセスできないなど詰む状況はあり得ます。
ソーシャルログインでも同じです。 OpenID Connectの啓蒙をしてきた中でも、「GoogleアカウントがBANされたらどうするんだ」「一時的にGoogleが使えない状況だったら」と指摘を受けまくってきました。
パスワード認証はもっとも詰みやすい方式と言えるでしょう。 詰んでいるので「パスワードを忘れた方はこちら」からメールアドレス入力画面へと遷移してリカバリーフローに入るのです。
- 個々の認証方式には必ず「詰みポイント」が存在する
- サービス側はその可能性などを踏まえて複数の認証方式を用意して当人認証をなんとか成功させられるようにしたり、身元確認してクレデンシャルの再設定を行うリカバリーフローや問い合わせ対応の仕組みを用意しています
なぜパスキーのリカバリーに注目が集まるのか
この辺りはパスキーの導入パターンと関係しています。
- 利便性観点 : 既存のパスワード認証 + 追加認証と同等の扱いとして導入
- (利便性に加えての)安全性観点 : ログインや特定機能の保護のためにパスキー認証のみに対応する形で導入、利用できない場合は問い合わせして本人確認
前者はパスキー認証を使うことで「便利に使える手段を増やす」ことを実現できます。一方で「最低の認証強度は変わらない」「別の方法でフィッシングにやられるかも」「パスワード認証を無効化できないなら意味ない」と言った反応をもらうこともあります。
後者は認証強度やAAL/IALと言った概念を導入し、一定の基準を超えるものだけを選択肢とする設計です。 パスキー認証で詰む条件とその後に求められるリカバリーフローの要件(フィッシング耐性やAAL/IALの設定)がある場合、ユーザーに課せられる負荷が高くなってしまうことがあり得ます。
サービスはパスキー認証を導入することで何を得たいのか、どのようなユーザーを保護するのかをよく検討し、ユーザーにとって高いハードルとならないための設計が必要となります。
現状はこの辺りを意識しているサービス、していないサービスそれぞれが存在しているので必ずしも良い印象を持たれていないと考えられます。 それぞれ「詰む」可能性のある認証方式とリカバリーフローをうまい具合に組み合わせて、ユーザーから見たときに「詰みにくい」認証フローを実現していく必要があります。
まとめ
- 全ての認証方式が詰む。パスキーも詰むし、ID連携でさえも詰む。パスワードはもっと詰む
- 「利便性向上」と「利便性+安全性の向上」どちらに重きを置くかという判断で導入パターンが変わり、前者より後者の難易度が高い
- サービス開発者は自サービスの特徴、ユーザーの利用形態などを踏まえた上で全体として「詰みにくい」フローを実現する必要がある
以上です。
この記事をDigital Identity技術勉強会 #iddance Advent Calendar 2024 5日目の記事として、終わりたいと思います。
ではまた！
