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

# 

パスキーは、「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](https://rmondello.com/2025/01/02/magic-links-and-passkeys/)


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

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

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

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

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

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

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

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

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


## まとめ

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

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

終わり。