WebAuthnでセキュリティとユーザビリティを向上させよう～WebAuthnがおすすめな理由 #2～

Webアプリケーションにおける認証に、WebAuthnをおすすめする連載の第二回です。

前回の記事ではWebアプリケーションの認証においてWebAuthnが比較的安全だとお話ししました。今回はその理由をご説明したいと思います。

WebAuthnが比較的安全と言える理由

その1、フィッシングに強い登録・認証の仕組み

まずは、WebAuthnの登録の流れから説明しますので、初回登録時の動画をご覧ください。

WebAuthnの登録を行う動画（ラップトップPC編）

WebAuthnの登録を行う動画（スマートフォン編）

動画の中でSMSも登録していますが、これはWebAuthnと直接の関係はありません。つまりWebAuthnを導入する場合には必ずSMSもセットで対応しなければならないということではありません。デモ環境がそのような設定であった、ということでご理解ください。もう少し説明を加えると、以下のようなことが行われています。

左側がエンドユーザで、カメラ付きのノートPCを使って登録する場面です。分かりやすくするために詳細を省いていますが、大まかな流れは図のとおりです。

また、生体認証する際の生体データ（この図の場合は「顔」のデータですが、顔でも指紋でも同様です）はサーバ側に送信されず、自分の端末の中に保管されます。なんとなく、サーバ側に自分の生体データが送信されてしまうのではないか、それがどこか他所に漏れたらと懸念されている方もいるかもしれませんが、サーバ側に送信されることはありません。

次は認証時の流れです。

登録時とほとんど同じですが、認証時には既に鍵があるのでその秘密鍵を使って署名し、それをサーバ側に送ります。サーバ側では保存済みの公開鍵を使って検証します。つまり、ユーザの手元にある秘密鍵を入手しない限り、正しい署名ができない、公開鍵で正しく復号できないということなので、フィッシングサイトで中継されても問題ないと言えます。

その2、管理対象を増やさない

連載第一回目で紹介した、Cloudflare社の公式ブログで紹介された攻撃事例を覚えていますか？スミッシングに引っかかってフィッシングサイトにアクセスし、ID/パスワードの他ワンタイムパスワードも入力してしまい、それらが脅威アクターに転送され転送された情報を使ってIDPサイト（正規サイト）にログインする高度なフィッシング詐欺です。

以下は、MFAを突破されてしまう図です。

MFA（時間ベースのワンタイムパスワードをSMSに送信するタイプ）を導入していますが、図のように「攻撃者」にリアルタイムに近い時間で送信するとMFAを突破されてしまいます。ちなみに、Cloudflare社ではFIDO2準拠セキュリティキーを使用していたので、MFAは突破されなかったとのことです。

さて、「FIDO2」というワードが出てきました。ここまで触れていませんでしたが、WebAuthnもFIDO2という認証技術を構成する技術の一つです。では、Cloudflare社のように、FIDO2準拠のセキュリティキーを使えば良いではないかと思う方もいると思います。正解ではあるのですが、セキュリティキー、つまりハードウェアや物品そのものの管理が必要になります。管理するということは、物品を購入し対象者に手渡す、簡易書留で郵送する、その社員が異動したり転職したりしたら返却を求める必要があります。これは大変ですよね......。WebAuthnなら、既に管理対象のPCやスマホくらいしか必要になりません。面倒な管理対象が増えないという点もWebAuthnをおすすめしたい理由です。

その3、フィッシング対策を考慮したセキュリティ

ここでは、WebAuthnを導入している環境でリアルタイムフィッシングを受けた場合を見てみましょう。

図のとおり、「攻撃者」は正しい秘密鍵を持っていないので、サーバ側にある正規ユーザの公開鍵で検証すると正規ユーザが署名したものではないことが分かります。これによって不正アクセスを防止できます。

次に、AiTM（Adversary in The Middle）によりMFAを突破される図です。

チャレンジも署名もそのまま転送されたらどうなるのかということですが、それでも大丈夫なのです。

では、WebAuthnを導入している環境で同じ攻撃を受けた場合はどうでしょうか？

もともとWebAuthnではフィッシング対策を考慮しているので安全と言えます。しかしそれではフィッシング対策として具体的に何を行っているのか良く分からないので、もう少し掘り下げます。

上図の⑦の部分、クライアント側ではサーバから送信されたチャレンジに加え、通信相手（origin）も対象にして署名する仕様になっていますが、図で示したAiTMにおいてoriginは「正規サイト」ではなく「フィッシングサイト（proxy）」となってしまいます。初回登録時の鍵ペアを作成した際のrpId（Relying Party：正規サイトのID）とoriginを比較し、一致していることを確認した上で署名する仕様のため、rpIdとoriginが不一致ということで異常を検出できる仕組みです。

仮に上記のチェック機構が何らかの手段ですり抜けられたとしても、図の⑨の部分で最後の正規サイト上での検証の際に、やはりoriginとrpIdが違うと、異常として検出されます。このoriginとrpIdの比較を行う部分が、フィッシング対策になっています。さらに興味のある方は、技術評論社やMDN Web Docsコミュニティーの記事、個人のブログで紹介している人もいるので検索してみてください。

さいごに

WebAuthnを導入して、セキュリティはもちろんユーザビリティを向上させてみませんか？
さて、最終回となる次回はWebAuthnを導入する際に考慮すべきことと、それらをまとめて解決できる手段についてご説明します。