パスキー時代のパスワードレス戦略

パスキーは、「UXが良く」、「フィッシング耐性がある」認証要素です。

この記事では、パスキーのデプロイメントの方向性として、

パスキーの「フィッシング耐性」ではなく、「UXの良さ」を活かして、サービスをフィッシングから守る

ということについて考えてみたいと思います。

パスキーのデプロイメントの特徴

パスキーの導入には、以下のような特徴があると思います。

「UXの良さ」を活かすのは簡単

パスキーのユーザー体験の利点を活かすのは比較的簡単です。

単にパスキーをログインオプションとして追加するだけで、ユーザーは便利な認証方法を選択できるようになります。

「フィッシング耐性」を活かすのは難しい

一方で、フィッシング耐性という利点を最大限に活かすためには、弱い認証方法（特にパスワード）を排除する必要があります。

しかし、現状、フィッシング耐性があり、かつUXが良い認証手段はパスキーしかありません。

そのため、パスキーのフィッシング耐性を活かそうとすると、パスキーが利用できない場合のUXが悪くなってしまうという状態になります...。（安易に弱い認証にfallbackするとそこから攻撃者に入られるから）

またサービスとしても、パスキーの登録をサービス利用の前提にすると、少なからずユーザが離脱するので、普通にやりたくない、という気持ちもあります。

現状とられているアプローチ

現在、多くのサービスでは、以下どちらかのアプローチをとっていると思います。

どちらも、それぞれRPの背景があり、どちらも課題が残ります。

パスキーをオプショナルにする

セキュリティ要件がそれほど厳しくないサービスでは、パスキーを追加の選択肢として提供し、従来のパスワード認証も残しています。

ユーザーは好みの方法を選べますが、パスワードという弱点は残ります。

システム全体としてはフィッシング攻撃に対して脆弱なままです。

パスキーを強制する

高いセキュリティが求められるサービスでは、パスキーを唯一の認証方法として強制することもあります。

これによりフィッシング耐性は高まりますが、パスキーが使えない状況でのユーザー体験が著しく低下します。

ユーザーが登録したパスキーを利用できなくなった場合や、パスキーをサポートしていない環境でアクセスする必要がある場合です。

パスワードレスに焦点を当てる

この問題に対処するため、視点を変えてパスキーではなく「パスワードレス」というに焦点を当ててみようと思います。

パスワードを排除することが目的であり、パスキーはその手段の一つの手段と考えてみます。

従来のパスワードレス手法の課題

これまで試みられてきたパスワードレス戦略には、以下のような課題がありました

UXの問題

• Email magic link: 別アプリへの切り替えが必要で、認証完了までの時間がかかります

フィッシング耐性の弱さ

• SMS OTP / TOTP: パスワードのセキュリティリスクを解消できますが、フィッシング攻撃に対しては脆弱です
• プッシュ通知: 通知疲れによって確認せずに承認するリスクもあるし、フィッシング攻撃に対しても脆弱です

普及率の低さ

• SNSログイン: すべてのユーザーが対応するSNSアカウントを持っているわけではありません
• セキュリティキー: 専用デバイスの購入・管理が必要で一般ユーザーには普及していません

つまり、「パスワードの脆弱性は回避できるけど、UXの悪さやフィッシングに対する弱さが残っている状態」、ということです。

パスキー時代のパスワードレス戦略

パスキーの登場により、新しいパスワードレス戦略が可能になりました。

それは、

パスキーの「UXの良さ」を活かしてパスワードを削除する

です。

このアプローチでは：

1. 通常の認証: 第一選択肢としてパスキーを使用
2. 代替手段: パスキーが使えない場合は、パスワード以外の認証手段を用意
3. 代替手段の条件: 代替手段は、UXが悪くてもいいから、フィッシングに強いものを選択

言い換えれば、

• パスワードの代わりに、「UXが悪くてもいいから、フィッシングに対して比較的強い方法」を使う

• 普段使う認証をパスキーにすることで、そのUXの悪さを補う

感じです。

代替手段の方に比重を置いてもいいでしょう。例えば、

• ユーザの環境でパスキーが使えないことがわかってる時は、代替手段を優先する、とか

• パスキーが使える可能性高い(Conditional UI)以外は、代替手段を優先する、とか

具体的な例

例えば、「パスワード + SMS OTP」から、以下に移行することを考えてみます。

• パスキー、もしくは、
• Email magic link + SMS OTP

このアプローチでは、システムの最も弱い輪が「パスワード + SMS OTP」から「Email magic link + SMS OTP」に変わります。

この方法のいいところは、

• パスワード + SMS OTPより、フィッシングに対して強い

• パスキー登録を強制する必要がないので、サービスを利用開始をブロックしない

※1 「email magic linkが本当にpasswordよりもフィッシング攻撃に強いんですか？」は、一定論がある気がするけど、今のところそう考えてる。
https://qiita.com/kokukuma/items/558e5fbc41078f75e1b9#magic-link-%EF%B8%8F

もちろん「Email magic link + SMS OTP」に、理論的なフィッシング耐性があるわけではないので、そのうち破られるでしょう。

その時はまた、許容可能な認証要素を探す旅に出るわけです。

そういえば、この組み合わせ前見たな、と、ここまで書いて思った。
Magic Links Have Rough Edges, but Passkeys Can Smooth Them Over

パスキーのフィッシング耐性の活用について

上のアプローチは、パスキーのフィッシング耐性を活かしたデプロイメントではありません。

weakest linkは、上の例だと、「email magic link + SMS OTP」です。

そのため、本当にフィッシング耐性のある認証を求めているサービス、つまり、

• パスワード+SMS OTPをなくすだけじゃ足りない

• 「Email magic link + SMS OTP」とか「CIBA + user_code」や破られるリスクも無視できない

の場合は...、仕方ないですね。

サービス利用開始時にパスキー登録して、サービス利用にはパスキー認証をさせるしかない、と思う。

でも、本当にそのレベルのセキュリティ求めてるサービスは、ごくごく一部だと思う。

まとめ

パスキーの登場は認証の新時代を開きましたが、その利用方法にはまだ課題があります。

「パスワードレス」という視点で考えることで、パスキーのメリットを活かしながら、現実的な認証戦略を構築できるかもなと思いました。

終わり。