パスキー認証の必須化/強制についての現状の課題と改善のための勘所

ritou です。

Digital Identity技術勉強会 #iddance Advent Calendar 2024 初日の記事です。今年も頑張りましょう。

パスキー認証の理想と現実

パスキー(というかFIDO)認証はパスワード認証を用いた脆弱な現状を打破すべく考えられた仕組みです。メディアの取り上げられ方はこんな感じでした。

とても安全で便利な仕組み
プラットフォームを跨いだ利用が可能
パスワードを置き換える

1の安全性については技術的に説明されています。最もシンプルな使い方であれば「慣れ」ることで便利さも感じられるかと思います。

2はプラットフォーマーやパスワードマネージャーが頑張っているところです。Appleがいち早く同一プラットフォーム、クロスデバイスな環境における同期を確立、Google Password ManagerはChromeが動作する環境でパスキーが同期されるというクロスプラットフォーム戦略に乗り出しました。Windowsも進捗が報じられています。現状への満足度はユーザーごとのデバイス利用スタイル、あるいは信仰により異なると思いますが、時間が経てばそれなりのところまでまではいけると信じています(お願いします)。

今回注目するのは3です。「パスワードの時代はオワタ。パスキーの時代が来るぞ」という売り込みだったわけで、それを見た人は当然ながら「パスワードがパスキーに置き換えられた時代」というのを想像してしまいます。そのため、続々と発表される「○○がパスキーに対応しました」と聞いて実際の挙動を見た結果「なんだ、パスワード認証の無効化まではできないんかい」という反応になったりします。そんな中で、いくつかのサービスは実際に「パスキー認証の必須化」に乗り出しました。

必須化に乗り出したサービスと嫌われるパスキー

必須化と言っても、いくつか種類があります。現状見かけるのは次の2パターンです。

特定機能を利用する場合はパスキー認証を必須とする
ログインする際にパスキーが登録されていたらパスキー認証を必須とする

前者の例で言うと、メルカリのパスキー対応の最初の頃はメルコインという機能で必須化されました。そして、dアカウントは今年7月からオンラインショップ(など?)でパスキー認証必須の対応がされました。

onlineshop.smt.docomo.ne.jp

後者で言うと、メルカリは全体のログインに対して、パスキーが登録されているユーザーに対してパスキー認証を必須にする対応を開始しました。

help.jp.mercari.com

他にも同様の対応が行われているサービスはあるようですが、自分のXの観測範囲で反応、というかdisが大きいのがこの2つのサービスです。

togetter.com

なぜ嫌われるのか

ネガティブな反応を生んでいる理由はいくつか考えられますが、大きいのは次の3つだと考えられます。

パスキーを知らない人に対しての説明、啓蒙が不十分
パスキーを必須化するフローのナレッジ、プラクティスが不足している
クロスデバイス、クロスプラットフォームの難易度が高い

それぞれ見ていきましょう。

不十分な啓蒙

1について、あるサービスがパスキー認証を実装し、ユーザーが使い始めるまでの啓蒙には次のようなステップがあると思います。

ステップ1: サービスの開発者にパスキーを知ってもらい、ユーザーとして使ってもらう
ステップ2: サービスの開発者にパスキーを自サービスに導入してもらう
ステップ3: ユーザーにパスキーを知ってもらい、使ってもらう

サービスに実装されないと使うも何もないわけなので、ステップ1としてはまずは開発者にパスキーってこう言うものだよ、まず使ってみてねと言うステップが必要でしょう。公開鍵暗号方式(の署名生成/検証の仕組み)が使われていてローカル認証が要求されるってあたりのざっくりとした解説、既に導入しているサービスのUXを見て何かを感じてもらうことで自サービスへの導入を検討してもらうことがGOALです。ちなみに知り合いのAuth屋さんのパスキー本はここを狙って書かれています。ｶｼｺｲ。ﾐﾝﾅﾖﾝﾃﾞ。

booth.pm

その次、ステップ2ではパスキー認証をサービスに導入するためのステップです。実装の基本となるパスキーの登録/認証で何が行われるのか、WebAuthnの使い方、既存のID管理の仕組みへの組み込み方といったところを覚えてもらい、自サービスに導入してもらうことがこのステップのGOALです。

私はFIDOアライアンスに無関係なので正確ではないかもしれませんが、FIDOアライアンスがしている啓蒙活動としてはこのステップ2に相当するものが多い気がします。パスキー認証は仕様自体やプラットフォームの対応が日々進められているので、一旦実装された後でもより使いやすいUXを提供するための改善を繰り返していくことも重要です。これはサービスだけではなく、ブラウザ、認証器それぞれにおいて言えることです。今は過渡期と呼ばれていると思うので、しばらくはわちゃわちゃしながらやっていくしかなさそうですね。そう言えば、まさにこのあたりをターゲットにしてそうなタイトルの書籍が1月に出るみたいです。内容どうなるんでしょうか。楽しみです。

パスキー導入・UX設計・実装リファレンス | えーじ, 倉林雅, 小岩井航介 |本 | 通販 | Amazon

こうしてサービスにパスキー認証が実装された後で、ステップ3のユーザーがそれを使うための啓蒙フェーズに入るわけですが、正直このステップの啓蒙についてはまだ十分ではないだろうと思っています。私は普段から「お前偉そうにパスキーの解説しまくってるけど、家族にその説明通用すると思うんか。全然わかりやすくないから。」みたいなことを言われることがたまにあるのですが、そりゃ開発者向けの啓蒙とユーザー向けの説明は違うでしょう。

では、ユーザー向けにどのような啓蒙が必要なのかということで、自分がユーザーに向けて言いたいことは「パスワードマネージャーを使いましょう」一択です。(追記: ブクマで指摘があったので補足します)これはパスキーを使うなという話ではありません。

メディアなどで語られるパスキー万歳の主張では、パスワードより優れたパスキーがやってきた！っていう感じで

パスキー ＞＞＞＞越えられない壁＞＞＞＞パスワード

という整理をした後に「新しい仕組みを使ってみよう、覚えてください」的な説明になりがちです。しかし、それでは心理的なハードルも高すぎて使おうとはならない気がします。そこで、間にパスワードマネージャーの話を入れて、2段階で説明してみましょう。

パスワードを「覚える」から「パスワードマネージャーで管理する」 : 推測可能なパスワードはだめよ、使い回しはダメよ、フィッシングサイトに入れちゃダメよ。でもそんなの覚えられないよね。まずパスワードマネージャーってのを使ってみてよ。難しいことはシステムに任せようよ。パスワードマネージャだけ他の人に使わせないようにできればいいよ。
パスワードマネージャーにより管理される「パスワード」から「パスキー」: パスワードマネージャーが作ってくれるのが文字列よりも安全なものになって自分でコピペとかもできなくなるし、それを入力するかどうかの判断の精度も良くなるよ。より難しいことをシステムがやってくれるんだけど、(Autofillにより)見た目もほとんど一緒だし、ロック解除してアプリを使うみたいな感覚でサービスを使えるようになるんだよ。

これだとどうでしょうか？全く別物であり越えられない壁がありそうだった両者を段階的に繋いでいけそうではないですか？

パスキー ＞＞＞システム管理されたパスワード＞＞＞覚えるパスワード

これが、パスワードマネージャーを使わせることが大事だという主張です。この辺りはまた別途まとめたいと思います。(追記終わり)

話を戻して、自分が関わるサービスがパスキー認証を導入する際に、説明文言などはニンテンドーアカウントが参考になるなぁという話が出ていました。

support.nintendo.com

パスキー認証を必須化のためには、これまで以上にユーザー向けの啓蒙が必要になると考えています。パスキーについて詳しくなってもらう必要はないというか無理だと思うので、とにかく「どうやったら使い始められるのか」「この場合はどうしたらいいか」と言う問いに対する答えを用意していって安心して使ってもらえる環境にすることが重要でしょう。

サービス側のナレッジ不足

次はサービス側の実装に課題がないのか、と言うあたりです。

先ほど

実装の基本となるパスキーの登録/認証で何が行われるのか、WebAuthnの使い方、既存のID管理の仕組みへの組み込み方

と書きました。

パスキーを用いたログインについてはある程度プラクティスもできていて、マネーフォワード IDが素晴らしいUXを提供できているようにAutofillに賭けておけば間違いないと言う感じはあります。

moneyforward-dev.jp

パスキー登録についても、Appleが対応したPasskey Auto UpgradeなどによるUX改善が見込まれています。ここまででわかる通り、現状において最もフォーカスが当たっているのは「パスワード認証 + αを使っていたユーザーのパスキーへの移行」です。パスキー認証の必須化については先行実装者によるチャレンジの段階な訳なので、あるサービスの開発者がそこに挑んで良いUXを手に入れるためのハードルは高いでしょう。パッと想像すると、

パスキー登録済みユーザーにパスキー認証を要求する
パスキー未登録ユーザーをパスキー登録フローに誘導する
パスキー登録済みかつ利用不可能なユーザーをリカバリーフローなどに誘導する

あたりが思いつきます。なんとかなるか、と思ったりもするわけですが、実際画面やフローを作り出してみるとそれこそWebAuthnの処理以外の部分で考えることが多いなーとなります。

(ブクマで指摘があったので追記)その中で、特に重要なのが最後のリカバリーです。パスキー認証が任意の場合、他の認証方式を使えですみますが、必須となるとリカバリーが必要です。具体的には、

KYCによる本人確認
パスキーのリセット

というあたりでしょう。Xでもメルカリに問い合わせてリセットしてもらったというのを見かけました。プラットフォームの対応のところで触れましたが、まだまだ同期されないパスキーを失ってしまうことはあり得ますし現状ではその可能性が小さくありません。(ちょっと前からこの話題は触れにくいんですけど)メルカリが仮にこの問い合わせ対応にすんごいコストをかけて迅速親切にKYC+リセット処理を捌けていれば、もしかしたらXで呪詛を吐かれなかった可能性もあると思います。ということで、必須化にあたってはリカバリーが誤魔化せない課題となるわけです。(追記終わり)

その辺りを含めて、既にパスキー認証の必須化に取り組んでいる皆さんは、ぜひその経験を活かしてプラクティスの作成やガイドラインの策定に繋げてもらいたいところです。

クロスデバイス、クロスプラットフォーム対応

最後に悩ましいのがクロスデバイス、クロスプラットフォーム対応についてです。メルカリの場合、モバイル端末でメルコイン用にパスキーを登録した後に、PCのログインでパスキー認証が求められて大変だったわ〜、みたいなのがXの反応から見て取れます。このクロスデバイス、クロスプラットフォームの利用時に詰まってしまう原因としては2つあるかなと思います。

Hybrid Transportsに非対応な環境なので技術的に詰んでいる
私はパスキーとやらを知らない。何もわからない

前者について、どうしてもHybrid Transportsがサポートされてない環境があることは知られています。これは仕方ないですね。あとはモバイル端末で登録したパスキーをPCで使うことはできるが、PCで登録したパスキーをモバイル端末で利用することはできない、という一方通行となるケースもあり、それにハマってしまうとなかなか辛いです。

このあたりについては、サービスの利用状況からパスキー認証の必須化に踏み切れるかどうかが決まってくるとも言えます。あるサービスを使う際に、

単一のモバイル端末のみ
単一のPCのみ
複数のモバイル端末
複数のPC
モバイル端末とPC...

と色々あるわけですが、単一のデバイス内で完結するのであればパスキー認証の必須化もある程度容易であると思います。しかし、モバイル端末とPC両方から使われるとなるとメルカリのような課題が出てきそうですねと。さらに細かくみると、(今はなんかごちゃごちゃしてますが昔の)LINEのようにモバイル端末の利用が中心、PCで利用する際にもモバイル端末を使ってログインできるみたいなサービスであればパスキー認証の必須化のハードルは低いでしょう。

開発者であればこの辺りの考えはなんとなく想像できるでしょうが、あまり明確に意識されてはいない気がします。ここで、2022年のプラットフォーマーの表明の際の実現させたい2つの機能みたいなのを思い出してみましょう。

www.apple.com

ユーザーは、新しいデバイスを含む多くのデバイスで、FIDOサインインの認証情報（「パスキー」とも呼ばれます）に自動アクセスできます。アカウントごとに再登録する必要はありません。

ユーザーは、使用しているOSプラットフォームやブラウザを問わず、自分のモバイルデバイスのFIDO認証を利用して、近くにあるデバイス上でアプリケーションやウェブサイトにサインインできます。

1が同期の話、2がHybrid Transportsのお話です。私の記憶では大体の人は1ばっかり注目してましたが、2も含めて考えるとパスキー認証においては(端末の故障、機種変更などにも耐えうる同期の仕組みを備えた)モバイル端末を中心にした運用というスタイルが想定されていたのだろうということですね。ユーザー向けの啓蒙の話に戻ってしまいますが、このようなモバイル端末中心の利用スタイルについても紹介することも重要になってきそうですね。

まとめ

今回はパスキー認証の必須化について、先行実装者が出てきているもののネガティブな反応もそれなりに見られるよという話をしました。 0から1を生み出す難しさは重々承知しているものの、この状況が続くことはエコシステムにおいてよくありません。サービスが嫌われるんじゃなくてパスキーが嫌われてしまうのもなんかアレです。

とはいえ、この状況で必須化に踏み込んだからにはサービスとしても何かしら負けられない戦いがあるのでしょう。 (今回のサービスの意図は知りませんが)例えば使いづらい！っていう怒られが発生したとしてもこれまでフィッシングでやられていた金銭的な被害がガクッと下がるのであればやる価値はあるみたいな判断はありそうです。今後も必須化の道を切り開いていくのであれば、現状を改善するためにできることをやっていって他のサービスも追従できるようになることを期待しています。