ritou です。
Developers Summit 2023にてパスキーについて講演させていただきました。
資料も公開しました。難しい話ではないです。
同じ時間帯の他の講演者の方々が豪華なのでワンチャン誰も聞いていなかった説がありますが、それもいいでしょう。とりあえず無事に終わりましたというところで、発表内容全部書き出してみたをやってみます。
講演内容
(省略)
今回の内容です。コンシューマ向けサービスにおけるこれまでの認証方式を振り返り、最近話題のパスキーとはどういうものかを紹介します。そして、実際に導入を検討する際に考えるべきポイントをいくつか紹介できればと思います。
早速、これまでのユーザー認証について振り返りましょう。
最初はパスワード認証です。知識要素を利用する認証方式であり、ユーザーとサービスがパスワードを共有します。
このパスワード認証を安全に利用するために、ユーザーとサービスそれぞれに要件があります。
もっとも基本的なところで、ユーザーはパスワードを忘れてはいけない、というものですが、残念ながら人間は忘れてしまいます。
そこでアカウントリカバリーと呼ばれる仕組みがあります。パスワードを忘れてしまった場合などに別の手段でユーザー本人であることを確認し、設定変更を行うものです。メールでリセット用のURLを送る方法が一般的かと思いますが、このような状態に陥らないようにあらかじめ別の認証方式を用意しておくのも一つの手です。
パスワード認証の要件に話を戻します。ユーザーは推測可能なパスワードの利用を避け、複数のサービスで使いまわさない、という要件もあるのですが、これも満たすことは困難です。また、サービスもパスワードを安全に管理しなければならないところを復号可能な状態で漏洩させてしまう事案が発生しています。
あるサービスから漏洩したメールアドレスなどの識別子とパスワードの組み合わせを利用してログインを試みるパスワードリスト攻撃、さらには識別子とよく使われているパスワード文字列を組み合わせてログインを試みるパスワードスプレー攻撃といったものがあります。厄介なのは、パスワードを安全に管理しているサービスでも他のサービスやユーザー次第で被害にあう可能性があるということです。そのため、パスワード認証と別の認証方式を組み合わせる2要素/2段階認証と呼ばれるものが使われるようになりました。
代表的なのはTOTPです。所有要素を用いた認証方式で、ユーザーとサービスが秘密鍵を共有してモバイルアプリなどが生成したOTPを認証に利用します。それまで金融機関やゲームなど一部のサービスではハードウェアトークンが利用されていたものの、配布コストなどもあり一般的にはなりませんでした。2010年代になってGoogleがGoogle Authenticatorを使った2段階認証を提供したあたりから一気に広がったと記憶しています。
同時に、SMSにワンタイムパスワードを送り、それを入力させる方式も使われ始めました。元々業者対策と呼ばれる、ユーザーの大量登録防止などで使われていましたが、これも2段階認証でよく使われるようになりました。ただし、サービス側がこれを使えば使うほど送信コストがかかりますし、遅延や届かないといったリスクもあります。
同様に、ワンタイムパスワードをメールで送信する方式も使われています。SMSの場合は契約しているSIMを持っている、といった制約から”特定端末への送信”とみなすことができますが、メールを受信できる環境というのはそれとはちょっと異なります。
他には認証用のモバイルアプリにPush通知を送り、受け取ったユーザーが許可するとログインできるという仕組みも使われています。少し前に、この通知を送りまくって精神的につかれさせ、気の緩みからログインさせてしまおうというMFA疲労攻撃というのが話題になりました。このような攻撃への対策として、PCなどの画面を操作してログインしようとしている人物と認証用のモバイルアプリを操作する人物の一致を確認するしくみもあります。例としては、PCの画面に表示された数値と一致するものをモバイルアプリで選択させるというものです。
ここまで紹介した認証方式のどれかを選びつつ、それが何らかの事情で使えなくなった際にユーザー自身で対応できる最終手段としてバックアップコード、リカバリーコードと言われる仕組みがあります。
これらの方法で先に紹介した攻撃への対策ができたのでもう安心、とはなりません。いわゆるフィッシングの問題が残っています。
ずーっと前から知られているフィッシング攻撃ですが、IPA情報セキュリティ10大脅威ランキングで個人向け2年連続一位となるなど最近も勢いは止まりません。そして重要なのはこれまで紹介してきた2要素/2段階認証を利用しても被害に遭う可能性があるということです。
少し前にAiTMと呼ばれる攻撃が起こりました。これはフィッシングサイトがユーザーと正規のサービスの中間者となるものです。ユーザーが入力してしまったパスワードなどを利用して正規のサービスにログイン試行を行い、最終的にログインセッションを乗っ取ってしまうものです。
仕組みを簡単に説明します。正規のサービスとフィッシングサイトがあります。
ユーザーは何らかの誘導からパスワードをフィッシングサイトに入力してしまい、フィッシングサイトから正規のサービスに送られます。
2段階認証が設定されていると、正規のサービスはSMS OTPやTOTPなどを入力する画面を返します。フィッシングサイトはそれをユーザーに表示します。
ユーザーがTOTPやSMSで受け取ったOTPをフィッシングサイトに入力すると、それが正規のサービスに送られ、ログインに成功します。
最終的に、発行されたセッション情報、具体的にはCookieやトークンをフィッシングサイトが取得できてしまう、という流れです。モバイルアプリへのプッシュやバックアップコードを使っても同様の方法でやられてしまいます。
このようなフィッシング攻撃に対し、ユーザーやサービスが取れる対策、緩和策がいくつかあります。ここではパスワードマネージャーとWebOTPを紹介します。
パスワードマネージャーはパスワードやTOTP設定をオリジン(ドメイン)と紐付けて管理し、一致しているものがフォーム入力時に補完されたり選択可能となる仕組みです。つまり、フィッシングサイトには表示されません。こうなったときに手動で入力をせず、何かおかしいかも？と気づけたらフィッシングの被害を避けられるかもしれません。
WebOTPでは送信したSMSメッセージに含まれるオリジン(ドメイン)とOTPの入力を促しているURLが一致していれば受信したSMSに含まれるOTPの値がフォームに自動入力されます。Google ChromeであればAndroidで受け取ったOTPをPCの入力フォームに転送することもできます。いつもこの挙動を利用している環境でなぜか今は手動での入力を求められるなぁというときには、フィッシングに気付ける可能性があります。ただし、どちらの方法でもユーザーが手動で入力すると被害にあってしまいます。よりシステムで防げるフィッシング対策が求められているわけです。
ここでいよいよFIDOの登場です。UserPresenseというのは、YubikeyやGoogleのTitanのように、セキュリティキーをPCに差し込んで端子の部分に触るだけで利用可能な仕組みです。具体的には公開鍵暗号方式が使われており、生成された鍵ペアというか秘密鍵がセキュリティキーに保存され、署名が利用するサービスに送られます。
さらに、PCやスマホの画面ロック解除に利用されるローカル認証によるUserVerificationを伴う仕組みでは、所有プラス知識もしくは生体の組み合わせとなり、単体でユーザー認証に利用できるという特徴があります。
FIDOのフィッシング耐性について説明します。FIDOをWebアプリケーションで利用するためのブラウザAPI仕様であるWebAuthnを利用すると、利用サービスが指定したオリジン、ドメインの値と現在のURLをブラウザが比較、不一致の場合は認証が通りません。システム的なところでフィッシング対策が取れる仕組みなのです。もちろん、ブラウザがパスキーというかFIDOに対応している必要があるわけですが。
図のようにFIDOによる2段階認証が要求されても...
フィッシングサイトに正規サービス用のクレデンシャルは送られません。ローカル認証と組み合わせた場合も同様です。
このようにフィッシング耐性を持つFIDOですが、課題もあります。セキュリティキーや端末など、秘密鍵が保存されている端末が使えなくなると、FIDOを利用している全てのサービスで再登録を行う必要があります。この手間を減らすために２つの端末からFIDOを使えるようにしておくべき、という話があるのですがこれも困難です。
いよいよここからパスキーの説明となります。
FIDOアライアンスの定義では、パスキーというのはFIDO Multi-device credentialsつまり、複数のデバイスで同期可能なFIDOクレデンシャルです。これまでセキュリティキーや端末の安全な領域に保存されていた”秘密鍵”がユーザーにより管理されるという表現が適切かと思います。パスキーの説明記事ではApple/Google/MSといったプラットフォーマーのアカウントに注目が集まっていますが、今後は1Passwordのようなパスワードマネージャーでパスキーを管理できるようにもなりそうです。これまでのFIDOにあった鍵管理の堅牢性は失われますが、バックアップを可能にすることで “フィッシング耐性を持ち利便性の高い認証方式” として普及を狙う方針です。
実際のパスキーの挙動を紹介します。今回はAndroidでWebAuthn.ioというサービスにアクセスしたスクリーンショットを貼りました。パスキーの登録時はサービスが指定したユーザー名でパスキーを生成しますか？という確認画面の後にローカル認証が要求されます。
ログインの際は、サービスがユーザーを識別した上でこのパスキーで頼む！と要求したらいきなりローカル認証が要求され、しない場合は登録されているパスキーから選択してローカル認証を行うことでログインできます。Android内で同期されている場合は別端末でも同様の挙動となります。
このようなパスキーですが、全ての端末、ブラウザで利用可能なわけではありません。細かく見ていくとプラットフォーム、端末、ブラウザの組み合わせ単位で非対応環境が存在します。iOS/MacOS/iPadOSのある程度以上のバージョンでSafariを使っていたら同期される、Android端末同士で同期される、MacOSのChromeで作成されたパスキーは同期されないみたいな状態です。パスワードマネージャーの話も含め、今後の対応環境の変化を見守っていく必要があるでしょう。
ここまでの流れではせっかくAndroidで同期されるパスキーを作ったのにMacOSで使えなかったら意味がない、となりそうですがhybrid transportという、別端末のパスキーを利用してログインする仕組みがあります。QRコードとBLEを使って近くにある端末と接続します。スクリーンショットではMacOSのSafariとAndroid端末を接続する様子です。これ、実際にやってみるとわかりますが、便利な仕組みなんですが何度も要求されるとなかなか辛くなります。利用する際はタイミングなどをよく考える必要があるでしょう。
もう一つ、ConditionalUI/Autofillと呼ばれる仕組みがあります。これは既存のログイン画面のユーザー名やメールアドレスを入力するフォームに登録済みのパスキーを表示して選択するとパスキーのログインフローに入れるというものです。既存の認証方式のUIにパスキーへのショートカットをつけられるイメージで使える機能です。
最後に、これからパスキー導入を検討する際の考慮点をいくつか紹介します。FIDOの利用方法などは既にドキュメントにされているものも多いですが、実際に導入する際に何を考えたらいいかはあまり整理されていないと思いますのでここで紹介します。
パスキー導入により何を実現したいかによって、導入パターンと考慮すべき点が変わってきます。「サービス全体、または特定機能の安全性を向上させたい」つまりある時点でユーザーに対してパスキー利用を必須にしたいところまで考える場合、登録やリカバリーといったタイミングの認証強度やサービスの内容と対応環境について細かく意識していく必要があります。一方で、意識の高いユーザーに対してパスキーを使ってもらえるようにしたい、ぐらいであればシンプルに認証方式を増やす感覚になるでしょう。
現状、FIDOアライアンスのイベントなどでもあまり語られていない部分で、ID連携との関係があります。これを紹介するのは私自身がOpenIDファウンデーションジャパンでエバンジェリストをしているから、という理由だけではありませんが、ID連携を提供/利用するそれぞれの立場でパスキー対応を行うメリットがあります。ID連携を提供するIdPがパスキーに対応すると、連携しているRelyingPartyもフィッシング耐性、利便性向上の恩恵を受けられます。これはIdPの価値向上につながるでしょう。一方で、RP側はIdP側の障害やアカウントBAN/凍結、突然のID連携停止といった、最近どこかで聞いたことのあるような状態でもサービスを利用してもらえるためのバックアップ的な認証方式として使うのに最適ではないかと考えます。
ここまでを踏まえて、導入パターンは3つぐらいあると考えています。メインの認証方式や特定機能を利用する際に必須化するパターン、オプショナルな認証方式として導入するパターン、導入済みのIdPと連携するパターンです。３番目について、OpenID ConnectではIdPで実施したユーザー認証の方式や特徴をRPに伝達するためのパラメータが定義されていますので、パスキーの普及に伴い使われていくことを期待しています。
パスキーをいつ登録させるか、登録時にどのような認証を求めるか求めないかは導入パターンにより変わってきます。パスキーを必須化したいパターンに当てはまるものに色をつけています。
ログインについても、細かい実装についてはドキュメントが既にたくさんありますが、非対応環境でどうフォールバックするかなどは考慮が必要です。
サービスの内容に応じて、再認証を要求するところがあります。パスキーの利便性を活かせる部分ではありますが、セッション管理と合わせて考慮が必要です。
バックアップが取れるようになったとはいえ、パスキーが使えなくなる状態はありえます。一度高くした認証強度を保つために、KYCなどを含めたリカバリーを検討する必要があるでしょう。
まとめです。
現状使われているユーザー認証方式の課題はフィッシング耐性です。パスキーはFIDO/WebAuthnのもつフィッシング耐性、ローカル認証の利便性を保ちつつ、バックアップによりリカバリーの課題を改善した仕組みです。導入パターン、考慮すべきポイントがいくつかあるので、自サービスに導入する際に留意してもらえると良いかと思います。
以上です。少しでも誰かの参考になればありがたいです。
今後は「自サービスにパスキー導入してみた」みたいな発表ができるように精進いたします。
ではまた！
Discussion