認証レベルの概念を取り入れたパスキー導入とユーザーへの影響

パスキー Authentication Security FIDO

おはようございます 自称パスキー👮‍♂です。

様々なサービスでパスキー対応が進む中で、今回は特定機能の保護を目的とした導入とユーザーへの影響について取り上げます。

きっかけ

ここ最近、🚔パスキーに関するパトロール🚔をしている中で、メルカリのパスキー導入についてこんなTweetを見つけました。

まずは１つ目です。

新しいパスキーを追加しようと思ったがパスキーがない。

事務局でパスキーをクリアしてもらった

別件で、2台めのAndroid端末で詰みかけた人がいました。

2台目の端末でパスキーが設定できない

1台目の端末からHybridで2台目につないでパスキーを作らないとダメ

マニュアル見てもわからん

この2種類のTweetを見るとメルカリのパスキー対応が単純にgdgdに見えなくもないですが、本当にそうでしょうか？ こういう意図でこうなってるんだろう、でこれを改善するために頑張るならここだよねみたいなお話をします。

認証強度、認証レベルとは

ユーザー認証の方式について、パスワード認証、ワンタイムパスワード、認証用のモバイルアプリ、FIDOなど様々なものがあります。 よく人類にはパスワード認証は早すぎるとか言ってそれぞれの特徴を並べて...とやってますが、今回はそれはやりません。 今回はこれらの認証方式にそれぞれ定義される認証強度、認証レベルといったものに注目します。

有名なものでいうとやはりNIST SP 800-63Bの定義でしょう。 FIDOアライアンスから以前出されたホワイトペーパーでもパスワード認証は1、(パスキー登場以前のデバイス単位にクレデンシャルが保存される)FIDOは3相当の扱いだと触れられています。

NIST（米国立標準技術研究所、National Institute of Standards and Technology）はこの状況をデジタル・アイデンティティ・ガイドライン、NIST Special Publication 800-63B に反映しています。このガイドラインでは、3 種類のセキュリティレベル（「AAL」、「認証器の保証レベル」）について概説しています。AAL1（最低レベル）はパスワード、AAL2 は（フィッシング耐性を必要としない）多要素認証、AAL3 はハードウェア ベースのフィッシング耐性のある認証メカニズムにおよそ対応しています。これらのセキュリティ・レベルに照らし合わせると、大多数のコンシューマーはオンライン認証の際に AAL1 を使用しています。多くのエンドユーザーは、例えばオンラインバンキングの利用時などに AAL2 を求められるようになってきていますが、AAL3 が求められることはほ とんどありません。

現在、FIDO 認証は、フィッシング耐性を備えたハードウェアベースの認証器によるもので、従来の AAL3 スタイルのスマートカード認証に代わる素晴らしい選択肢となっています。

参考URL:

openid-foundation-japan.github.io

speakerdeck.com

例えばMicrosoftは、NISTの定義を満たす認証器の組み合わせはこれですよというドキュメントを出していたりします。

learn.microsoft.com

このNISTのAALは様々なガイドラインで"参照"されているので、「この機能を利用するサービスはNISTのAALでこれを満たす認証器を利用する必要がある」みたいな制約があったらそれに従う必要があります。一方で、全てのサービスが必ずこの定義を使わなければならないわけではありません。 当然ながら、サービスが独自にAALを定義をして設計に利用することもありますし、NISTのAAL定義に沿った上で細かい優劣からレベルを定義して利用することもできます。 例えば、クレデンシャルが同期されることでNISTのAAL=3を満たせないと判断されるようになっているパスキーですが、フィッシング耐性という点で他の認証方式(SMSや認証アプリなど)とパスワード認証を組み合わせたものよりもレベルが高いもの、として扱うなどです。 自分が関わるサービスではパスワード認証を利用していないので、SMS/Email OTPでの認証レベルを "一番低いもの" 、パスキーとして同期されうるようになったFIDOクレデンシャルの扱いをざっくり "それより高いもの" としてサービス独自のAALを定義しています。 この後説明しますがメルカリもそんな感じなのではと想像しています。

単純にログイン方法を増やす目的でパスキーを採用！という場合は、特にこのような認証レベルを意識する必要はありませんが、決済、金融関連やヘルスケアのようなセンシティブなデータを扱う機能を保護するためにパスキーを採用する場合は認証レベルを意識する必要があります。 最初に取り上げたメルカリの挙動も認証レベルを意識した設計となっていることにより生まれたものと言えるでしょう。

メルカリのパスキー管理と認証強度に対するポリシーを想像してみた

3行 + αで説明すると、こんな感じなのかなというところです。

  • ビットコイン関連取引ではパスキーの認証が必要
  • パスキーの認証を行うためにはパスキーの登録が必要
  • パスキーの登録時にその時点の最大の認証レベルを実現するための認証方式が要求される
    • パスキーが設定されていない場合はSMS OTPによる認証
    • パスキーが設定されている場合は登録済みのパスキーを用いた認証

例えば、悪意のある攻撃者がAiTMなどでパスワード + SMS OTPを取得してログインセッションを奪い取ることを想像してみましょう。 HTTP Cookieなどで実現されるログインセッションを取得できた攻撃者は、自分自身の端末でログイン状態を再現しつつSMS OTPの値を中継してパスキー登録といった攻撃も考えられなくはありません。若干めんどくさいですが技術的には可能でしょう。

メルカリではこの脅威を認識し、リスク軽減のための設計として以下のように

  • まだパスキーを設定していない状態では、SMS OTPで確認したユーザーを本人とみなすしかないので、(環境判定なども可能なものの)そのまま設定させる
  • 2個目のパスキーを登録する場合は1つ目のパスキーを用いた認証の方がAALが高いため、そちらを要求するという仕様となっている

となっていると想像できます。ここまでは特に筋が悪いものでもないですよね？

「せっかくパスキーが登録されているのに、それより認証レベルが低い認証方式でパスキーを登録させるわけにはいかんよね」というメルカリ側のポリシー と、「パスキー＝同期されると言えどもプラットフォームが異なったりブラウザ、端末の関係によっては同期されないことがあるんよな」という実情 の噛み合わせにより、どうしても詰んでしまうケースが出てきてしまうというのが最初に紹介したTweetにつながっています。

設計のポイントは、ユーザーがとりうる認証レベルの最大値

メルカリのような特定機能を保護する目的でパスキーに対応しようとする場合、重要なのは "ユーザーが取りうる認証レベルの最大値" を把握できるようにすることです。

メルカリは毎回認証を要求されるわけですが、そうではなくログインは最初の一回だけで必要ならば追加認証や再認証を要求するといった実装も考えられます。サービスのセッション管理や再認証のポリシーなんてのは本当にサービスに依存するわけですが、例えば

  • メルカリのように都度認証を要求する場合、その時に取りうる認証レベルの最大値を実現する認証方式を要求する
  • 都度認証は要求しない場合でも、現在のセッションの認証レベルとユーザーが取りうる認証レベルの最大値を比較して最大値に足りない場合は再認証を要求する
  • さらに最終ログイン日時や環境判定などを組み合わせる

といった設計が必要となり、最も基本となるのが認証レベルの最大値なのです。

同期が可能なパスキーでもリカバリーは重要

パスキーをApple/Google/MSが表明した際、たくさんの人が「プラットフォームを超えて鍵が同期される？なんか良さそう！」って感じになりました。実際はプラットフォーム単位だったり、AppleはクロスデバイスなのにGoogleはAndroid端末同士の同期だったり、MSは何してるんだろと思ったら最近やっと対応始まったみたいな感じになってたり「これじゃない感」が出ました。

残念ながら、どうしても「パスキーを設定しているのに使えない状態」というのが存在します。そして、厄介なのがパスキーの認証強度は他の認証方式よりも高いため、代替の方法を用意することが現状では困難だということです。

今回注目したメルカリでは詰んだ時に、どうするか、というところで、

  • 最初にパスキーを登録した端末ではパスキー認証ができるわけなので、その端末からQRコードでモバイル端末などのパスキーを登録して使えるようにする
  • 登録済みのパスキーをCS側でリセットすることで、パスワード + SMS OTPを最大の認証強度として扱うように戻し、新しい端末からも再度パスキーを登録可能にする

ユーザー自身の対応ができるとクレーム含め問い合わせを回避できます。しかし、例えばTOTPとバックアップコードのようにパスキーと対になる方法が確立されているとは言えません。そのような状況において機種変更で古い端末を回収/廃棄されてしまった場合はユーザー自身による対応は困難ですし、Hybrid Transportも全ての端末間で相互に利用できるわけではありません。

ユーザー自身で対応することができないケースを救うため、CS対応において本人を確認した上で後者のようなことができます。 ここからはパスキーと関係ない部分ですが、決済機能を扱っているなど、いわゆる本人確認の仕組みで本人確認書類を提出して属性情報を検証しているサービスの場合はそれを使って本人が問い合わせをしてきたことを確認したりします。そこがうまくできれば、その後のリセットや一時的なパスキー登録を許可する仕組みを用意することもできるでしょう。 最近というかずーっと色々言われているマイナンバーカードを用いた認証の仕組みや、今後作られると言われているスーパー認証アプリ？みたいな仕組みでこの辺りの負担を減らせるようになることを期待しています。

まとめ

  • メルカリは特定機能を保護するためにパスキーを利用しており、パスキーの登録時にはユーザー毎に最大強度の認証方式を要求するため、新しい端末などで登録済みのパスキーが使えない場合に影響が出る
    • 最初にパスキーを登録するとそれが最大強度の認証方式となり、その後はパスキーが同期されている端末もしくは手元でパスキーの認証が可能な端末からHybrid Transportで2台目を登録する必要がある
    • CS経由でパスキーの設定をクリアすることで最大強度の認証方式がパスキーではなくなり、そこからまたパスキーの登録が可能となる
  • セッション管理のポリシーはサービス毎に異なるものだが、認証強度(AAL)の値と認証方式の組み合わせを使って設計するのが良さそう
  • プラットフォームアカウントによる同期は完全ではないので、なるべくユーザー自身で実現可能なリカバリー方法を用意しておきたいが悩ましい

今回取り上げたメルカリと同様に、特定機能を保護する目的でパスキーに対応するサービスが今後は必ず出てきます。これは断言できます。 メルカリにはもう少し人柱的な立ち位置でがんばってもらいつつ、 少しずつこの辺りのユーザー教育と回避策の検討などを頑張り、パスキーの安全性を利用できる世界にしていきましょう。

ではまた！