Money Foward Tech Day 2024
こんにちは、@nov です。
先日 2024/09/20、Money Foward Tech Day 2024 というイベントで Passkey Autofill に賭けるマネーフォワード ID というお話をさせていただきました。
その時に使ったスライドはこちらに公開してあるのですが、スライド内の文章は日英併記が必要で、スライドレイアウトの調整が難しかったため、このスライドにはほとんど文章を入れていません。
結果として、このスライドだけでは、イベントに参加していなかった方々には内容が伝わりにくいと思いますので、ブログにも書き起こしておこうと思います。
マネーフォワード ID について
最初の方は自己紹介とかマネーフォワード ID についての紹介なんで改めてお話しすることはありませんが、マネーフォワード ID における Sign-in Methods 利用率のグラフは最後の方の Passkey Auto Upgrade の話とも少し関係してきますし、今後のパスキー利用状況レポートでどれくらい Passkey が増えていっているかを判断する基準にもなるでしょう。
パスワードは弱い
先日、マネーフォワード ID でも不正ログインが発生して、マネーフォワードクラウド請求書からフィッシングメールのようなメールが大量に送信されるという事件がありました。その話も交えながら、「みなさんが使い回しているパスワードは、すでに何処かから漏洩している可能性があり、同じパスワードを登録しているどこかのサービスに不正ログインされてもおかしくないんじゃないですか?」という注意喚起を行ったのがここの導入部分でした。
当社ユーザー以外の第三者によるアカウント不正利用および大量のメール送付に関する注意喚起
パスワードマネージャーを使用して生成されたパスワードは決して弱くはありませんが、16文字を超えている、使用できない記号が含まれている、半角英字の大文字・小文字・数字・記号がすべて含まれていないなど、各サービスごとに異なるルールによってエラーが発生することがあります。その結果、「100回登録を試みて20回くらいエラーに遭遇した場合、ユーザーはパスワードマネージャーを嫌いになるでしょう」というお話がこのセクションのハイライトです。
つまり、強力なパスワードを生成するパスワードマネージャーに対して、ユーザーが敬遠する原因を作っているサービスが存在し、エコシステム全体を弱体化させているということです。
結局、いくら部品が強くても、ユーザーが同じパスワードを使い回したり、サービスが平文でパスワードを保存して漏洩する事故が起きたり、パスワードマネージャーが作る強いパスワードを受け付けられないサービスがあることで、エコシステム全体としては「Strong x Weak = Weak」で弱いままなのが、いまのパスワードの問題点です。
Passkey に賭けるマネーフォワード ID
FIDO Alliance が定める FIDO というプロトコルと W3C が定める WebAuthn という JS API に従って、ローカルで生体認証したのちに公開鍵暗号方式による署名を施したアサーションを発行して...みたいな話は今日はしません。Passkey というのは、(実態として99%以上が) Password Manager に保護された鍵だと、それだけ覚えてください。という話が前半。
そして Passkey を登録しようとすると、Touch ID や Face ID が求められたのちに、最終的に FIDO Attestation というものが発行され、それがサーバー側に登録されます。この複雑な FIDO Attestation というバイナリーデータを検証するためには、FIDO というプロトコルに従った検証処理を行う必要ですが、これには16文字を超える、利用できない記号が含まれている、半角英数字の大文字・小文字・数字・記号がすべて含まれていないといった独自のルールによるエラーは発生しません。結果、パスワードマネージャーに作られたパスワードのように同じルールに従ってもサイトによっては登録時にエラーになる、なんてことも起こり得ません。
その結果、強いパーツが嫌われることもなく使われるのであれば、それはそのままエコシステム全体として強くいられそうな気がしませんか?
それが、マネーフォワード ID が Passkey に賭けている最大の理由です。
Passkey は強いです。パスワードマネージャーが作るパスワードも同様に十分に強いです。ではその差は何でしょうか?
ユーザーに嫌われるか否かです。
Passkey Autofill に賭けるマネーフォワード ID ~ Passkey UX Challenge
と、「Passkey に賭けるマネーフォワード ID」をした後に、いよいよ本題へ。
マネーフォワード ID が Passkey に賭けているのはもちろんのことですが、本当に賭けているのは Passkey Autofill なんですよ。
なぜかって?Passkey 自体の UX は素晴らしいですが、まだ完璧とは言えない部分があると感じているからです。
3大プラットフォームのいずれか1つ (僕の場合は Apple) に囲い込まれている僕のようなユーザーは、iPhone で登録された Passkey が iPad でも Mac でもそのまま使えてなんの問題もない1のですが、Android と Windows を使っていたりすると、その間では片方にしか Passkey が存在しないなんてことも容易に起こり得て...
Passkey が存在しない端末でログインしようとした場合、サービスによっては謎の QR コードをスキャンするよう促すプロンプトが現れたり、謎の「セキュリティーキー」なるものの使用を提案されたり、キャンセルしたらいきなり「エラー」というメッセージが表示されたり...
これでは、パスワードマネージャーが作るパスワードと同じ目に合うのが目に見えています。
こういうのは、ユーザーが Passkey を嫌いになる要因にしかなりません。これじゃダメなんです。2
というのが Passkey Autofill の話の前置きで...
Passkey Autofill に賭けるマネーフォワード ID ~ Passkey Autofill UX
これが、Passkey Autofill を使えば、無駄なエラーを出さずに済むようになるんです。
Mac Safari だと、端末上に当該アカウントの Passkey が保存されていない場合 (= nov@caulis.jp
アカウント) はパスワードが、Passkey が保存されていれば (= nov@matake.jp
アカウント) Passkey がサジェストされます。大抵のユーザーは、両者の区別などつかず、つまり当該端末上に Passkey が保存されているかどうかなど気にせずに、ログインしたいメールアドレスを選ぶだけで良いのです。
iPhone Safari でも同様です。Passkey が保存されている端末上では左のように「パスキーを使用」というボタンが現れ、保存されていない端末上では右のように「パスワードを入力」というボタンが現れますが、どちらもほぼ似たようなプロンプトで、あえて区別をつけなくてもそのまま使えるようにデザインされています。
ログインフロー全体を通してみても、Passkey Autofill によるログインと、パスワードマネージャーのパスワード自動入力機能によるログインの UX はほぼ同じで、ログインしたいアカウントを選択し、Face ID を行えば、ログイン完了です。Passkey かパスワードかの違いを意識する必要はありません。
未解決の Passkey UX Challenge
セッションの最後は、少しだけ Autofill のその先の話をしましょう。
Passkey Autofill により、Passkey を使ったログイン時の UX Challenge は解決されます。もう嫌われる原因になるようなプロンプトやエラーを見せる必要はありません。
でも、まだ登録時の UX には課題が残っています。
いまマネーフォワード ID では登録直後や TOTP 設定直後に以下のようなパスキープロモーションページを表示して、Passkey の登録を促しています。
プロモーションページの内容は専門的で、一般のユーザーにとっては理解しにくいかもしれません。さらに、「このデバイスを登録する」をクリックした際にブラウザに表示されるプロンプトも、その意図がすぐには理解できない場合があります。
結果として、このプロモーションページでは、訪問者の3-4割がそもそも「このデバイスを登録する」を選ばずスキップし、「このデバイスを登録する」を押したユーザーのさらに3-4割がプロンプトの「キャンセル」を押してエラーになります。
全体として Passkey Registration CVR は 50% 程度と低い状態です。
これが Passkey に残された最大の課題でしょう。
結果として、このような表示が続くと、ユーザーはPasskeyに対して否定的な印象を持つかもしれません。
解決策1 : Passkey Auto Upgrade
上述の Passkey 登録時の UX 上の課題を解決する1つめの策は、すでに Apple が最新 macOS / iPadOS / iPhone OS に実装済みの Passkey Auto Upgrade という機能です。
詳しくは Streamline sign-in with passkey upgrades and credential managers - WWDC24 を見ていただくとして、Passkey Auto Upgrade を使うと、以下のようなフローでパスワードマネージャー上のパスワードが Passkey に自動でアップグレードされます。
Tech Day 2024 の発表時点ではマネーフォワード ID における Passkey Auto Upgrade サポートはまだ社内ユーザー向けの限定公開機能でしたが、現時点ではすでに全ユーザーに解放されています。
この機能により、ユーザーはパスワードマネージャーを使ってさえいれば、自動的に Passkey の登録が完了し、なんのエラーも見ることはありません。
すでにマネーフォワード ID では、Passkey Auto Upgrade による Passkey 登録数がプロモーションページを含む全経路の Passkey 登録数の合計をも超えている状況で、近い将来、前述の Sign-in Methods の中で Passkey が占める割合が 20% 程度にまで上昇するであろうことまでは予想できます。3
ということで、Passkey Auto Upgrade は Passkey 登録の UX 上の課題を解決する有望な機能ですが、結局のところパスワードマネージャーにパスワードが存在しないと使えない機能であり、パスワードを完全に無くすに足るものではありません。
解決策2 : Passkey Autofill Registration
最後の話は完全なる僕の妄想です。
かつて以下の GitHub Issue で軽く提案してみたことはあるものの、Reject されているので、特段これが使用策定者によって議論されるだとか、どこかのベンダーがこれを実装するだとかいう段階には全くありません。
が、個人的には数年間ずっと「パスワードマネージャーが自動的にパスワードを生成してパスワードフィールドに Autofill するように、パスワードマネージャーが自動的に Passkey を生成して Autofill してくれれば、Passkey がパスワードを置き換える準備は整う」と信じています。
それができれば、当然「パスワードを忘れた」時のパスワードリセットも、パスワードを変更する時も、ユーザーにはパスワードマネージャーが作るパスワードを登録しているように見せながら、Passkey を登録 / リセット / 変更することができます。
ここまでくれば、ユーザーがパスワードを登録することはなくなり、真の意味でパスワードの無い世界が現実のものとして見えてくるでしょう。
最後に
今回は「マネーフォワード ID」を舞台として Passkey の話をしましたが、本当に僕が伝えたいことは、エコシステム全体で Passkey を「STRONG」にするためにどうするべきかという話です。
このセッションを聞いた、この記事を読んだみなさんが、各自が関わるサービスにおいて、同じ方向を見ながら進んでいけたら、いつかもっと安全なエコシステムが築けるのではないかと願っています。
今いる僕らが年老いて、次に来る若い世代が現れた時、彼らがパスワードを使っていないことを祈りながら...
- 実際には会社の Mac と個人の Mac で異なる iCloud Keychain アカウントを使っていることにより、個人の iPhone で登録した Passkey は会社の Mac では使えていないので、Apple に囲い込まれていても Passkey Platform の分断は起こり得ます。↩
- Tech Day 2024 後の話ですが、Xのタイムラインで嫌われるパスキーについてつぶやいている方がたくさんいました。もう猶予はそんなにないかもしれません。↩
- Passkey Auto Upgrade 導入前後の変化ついての詳細は、近日公開予定のパスキー利用状況レポートでご紹介できるでしょう。↩