WebAuthn運用検討編
こんにちは。次世代システム研究室のT.Tです。
現在開発運用に携わっている認証サービスにWebAuthnの導入を検討中です。WebAuthnは主なブラウザでのサポートが進んで来ていて、2020年9月17日にSafari 14でTouch IDとFace IDでのWebAuthnの認証デバイスとして対応されたことで今後更なる普及が期待される認証技術です。
https://media.fidoalliance.org/wp-content/uploads/2020/06/Screen-Shot-2020-06-30-at-8.11.50-AM.png
WebAuthnの概要とユーザー登録、ユーザー認証の仕組みについては以前次世代システム研究室のブログで紹介されていますので、本ブログではサービスにWebAuthnを導入するに当たって運用面で考慮すべき点を中心にまとめていきたいと思います。
1.WebAuthnの概要
1-1.WebAuthnの概要
WebAuthnは2019年3月4日にW3Cの勧告になりました。WebAuthnはブラウザ経由で携帯端末等の生体認証機能と連携することでパスワードレス認証を実現する仕組みです。この認証システムではID/パスワードを使わず公開鍵/秘密鍵の組み合わせを利用して認証を行います。これによりユーザーはパスワードの暗記が不要になることによる利便性の向上やパスワードの流出によるアカウントへの攻撃を防ぐ効果があります。
一方、認証に必要な情報を携帯端末等の物理デバイスの認証器に保管するため、認証器の紛失・盗難等により認証情報が流出することへの対策、またサービス提供者側での公開鍵の保管等、サービス運用で注意しなければいけない部分もあります
1-2.認証フローの概要
認証時のフローは下図のようになります。
まず、クライアントがチャレンジを要求し、これに合わせてユーザーIDを送信します。チャレンジはサーバー側で認証をする際に、認証をリクエストしたユーザーがユーザーIDの保有者と一致することを確認するために使用するランダムな文字列(署名用の文字列)です。その後サーバーからチャレンジを受け取り認証器に認証をリクエストして認証を通して署名を受け取ります。それからその署名をサーバー側に送信して、サーバー側で署名による本人確認が通るとサーバー側でも認証が通った状態になります。
2.導入対象の認証サービスの概要
WebAuthnの導入を検討している認証サービスは、当社グループ会社が提供している様々なサービスから利用される認証サービスです。認証サービスは連携しているサービスで認証が必要になる際に呼び出され、呼び出し元はWebAuthn用の認証器が利用できる携帯端末であったり、そのような認証器を備えていな端末である可能性もあります。
現在は認証方式として自サイトでのパスワード認証と外部のIDサービスによる認証を提供しています。その外部のIDサービスでWebAuthnでの認証を提供しているサービスがあるためそこを経由してWebAuthnが利用できますが、今回は自サイトの認証方式としてWebAuthnの導入を検討しています。
下図はWebAuthn導入後の認証フローのイメージ図です。
3.関連するユーザーシナリオ
認証サービスを利用する連携サービスの種類は様々なものがあるので、それを踏まえていくつかのシナリオについて検討してみます。
3-1.認証器の紛失・盗難
認証器の紛失・盗難はWebAuthnを導入するに当たって注意深く議論されるべきトピックの一つです。認証器を紛失することでログイン不能になったり、悪意のあるユーザーによるアカウントへの不正なアクセスの可能性があるためです。
このケースについてWebAuthnの仕様では取り決めがないようですが、セキュリティの項目で言及されています。認証サーバー側でユーザーアカウントに複数の認証器を登録できるようにして、それぞれの認証器でログインできるようにしておけば良さそうです。認証器を紛失した際は別に登録してある認証器側でログインができ、紛失した認証器の認証情報を削除することで不正なアクセスも防げます。WebAuthnでは携帯端末から切り離せるYubiKey等のローミング認証器もサポートしているので、このようなデバイスと組み合わせることでうまく対処できそうです。しかし、複数認証器やローミング認証器を使うユーザーはあまり一般的ではないと思うのでパスワード認証等の知識要素での認証の併用やユーザーサポートでの対応も考えておくべきだと思います。
3-2.単一ユーザー複数デバイス
サービスを日常的に複数のデバイスで利用するケースです。WebAuthnでは先述した同一アカウントでの複数認証器を登録して利用したり、各デバイスで共通のローミング認証器を使って認証する仕様もあるのでこのケースには普通に対応できそうです。
3-3.単一デバイス複数ユーザー
携帯端末等を他のユーザーと共有して利用するケースです。WebAuthnでは携帯端末での生体認証とPINコードの入力による認証の区別が出来ないため注意が必要です。このケースではPINコードは各ユーザーで共有されていると思うので、サービス側では決済やユーザー情報更新等の必要なタイミングでパスワードで再認証するのが望ましいケースもあると思います。
3-4.ネイティブアプリ
連携するサービスによってはネイティブアプリも提供しています。他のサービスではブラウザ経由でWebAuthnでの認証を使っていて、他のネイティブアプリを使っているサービスでも生体認証を使うケースが考えられます。
Webビューを使っているネイティブアプリであればWebAuthnの仕組みがそのまま使えそうです。AndroidはFIDO2のライブラリがあるのでこれを使えば比較的簡単に認証サービスとの連携ができるかもしれません。ネイティブアプリとの連携はあまり詳しく把握できていないので引き続き調査していきたいと思います。
4.パスワードレス化について
ユーザーはWebAuthnを提供している認証サービスを利用することでパスワードレスでサービスを利用できるようになり、パスワード認証をオプション化することでリスト型攻撃への対策が出来てセキュリティも向上することができます。
一方、いくつかのユースケースを見ても認証サービス側はパスワード認証等の知識要素の認証を捨て去ることは難しく、WebAuthnの分だけ開発運用のコストが大きくなりそうです。パスワードレスは利用者視点の話として割り切るのが良さそうです。
5.その他のパスワードレス認証との比較
パスワード認証のような知識要素と指紋認証や顔認証による生体要素以外に、SMS認証やワンタイムパスワードといった所有要素による認証方式が考えられます。自サイトには所有要素による認証も導入できていないので、こちらについても検討してみました。
Yahoo! JAPAN研究所でのWebAuthnを用いたパスワードレス生体認証のユーザビリティ調査によると、生体認証とSMS認証は共にユーザビリティとセキュリティの面でパスワード認証より優れているという結果が得られています。
所有認証ではセキュリティ面でSMS認証が優れていると思いますが、導入する場合は一通10円前後の従量課金で利用することになると思うのでコスト面も考慮する必要があります。
6.まとめ
認証サービスとしてWebAuthnを提供することでユーザーに利便性とより高いセキュリティを提供できます。サービス提供事業者はその認証サービスと連携することでWebAuthnの煩雑な運用を考慮せずに認証の利便性を高められます。WebAuthnだけでは様々な利用シーンでの要求を充足できないですが、知識要素と所有要素の認証方式と組み合わせることでより多くの利用シーンでの活用が見込めます。現在開発運用に携わっている認証サービスに導入を進められるように引き続き検証と開発に取り組みたいと思います。
次世代システム研究室では、アプリケーション開発や設計を行うアーキテクトを募集しています。アプリケーション開発者の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ 募集職種一覧 からご応募をお願いします。
皆さんのご応募をお待ちしています。
