パスワードだけでは不安なので、Google Authenticatorなどの認証アプリを使って2段階認証を設定している人も多いと思います。
そこに最近増えてきたのが「パスキー」です。
パスワードを入力せず、指紋認証や顔認証、端末のPINなどでログインできるため便利ですが、気になるのは安全性です。
すでにパスワードと認証アプリを使っているなら、わざわざパスキーへ変える意味はあるのでしょうか。
調べてみると、答えはかなり明確でした。
フィッシングや認証情報の窃取に対しては、パスキーには「パスワード＋認証アプリ」より明確な強みがあります。
ただし、パスキーにすればアカウント乗っ取り全般を防げるわけではありません。
違いを理解するには、ログインするときに何を攻撃者へ盗まれる可能性があるのかを見ると分かりやすくなります。
パスキーは「パスワード＋認証アプリ」より本当に安全？
今回比較するのは、パスワード＋認証アプリを使った2段階認証（TOTP方式）と、パスキーです。
TOTPは、認証アプリに表示される6桁のコードをパスワードに加えて入力する方式です。
パスワードだけよりかなり安全で、仮にパスワードが漏れても、攻撃者は通常TOTPのコードも用意しなければログインできません。
では、パスキーにする意味はあまりないのでしょうか。
そうではありません。
大きな違いが出るのが、フィッシングです。
TOTPも十分有効ですが、パスキーではさらに防ぎやすくなる攻撃があります。
TOTPを使っていても、なぜフィッシングを防ぎきれない？
TOTPの6桁コードは短時間で無効になりますが、その間に攻撃者がリアルタイムで使うことはできます。
本物そっくりの偽サイトにパスワードとTOTPコードを入力すると、攻撃者がそれをすぐ本物のサービスへ転送し、認証に利用する可能性があります。
TOTPそのものが弱いわけではありません。
問題は、6桁コードを人間が読み取り、偽サイトにも入力できてしまうことです。
そのため、
「TOTPは役に立たない」のではなく、「TOTPでも防ぎきれないフィッシングがある」
と考えるのが正確です。
では、パスキーはなぜフィッシングに強い？
大きな違いは、パスキーの認証情報が正規のWebサイトに結び付いていることです。
TOTPでは「このサイトは本物か」を人間が判断してコードを入力します。
一方、パスキーではブラウザやOSなども認証先を確認するため、偽サイトに認証情報を渡してしまう攻撃が成立しにくくなります。
今回調べてみて、パスキーの強みを一番分かりやすく表すなら、
「人間が偽サイトへ渡せる認証情報を減らしている」
ということだと思います。
パスワードもTOTPコードも、人間が見て別の場所へ入力できます。
パスキーは、その部分を人間の注意力だけに頼らない仕組みに変えています。
パスキーに変えても、防げない乗っ取りはある？
あります。
パスキーが強くするのは、主にログイン認証の部分です。
そのため、パスキーを使っていても、
- 端末そのものがマルウェアなどに侵害される
- ログイン後のセッション情報を盗まれる
- メールやSMSなど、別の弱い復旧経路を悪用される
- 従来のパスワードログインが残っている
といった攻撃は別に考える必要があります。
また、パスキーを追加しても、古いパスワードや弱い復旧方法が残っていれば、攻撃者はそちらを狙えます。
「パスキーそのものが強い」ことと、「アカウント全体が安全になる」ことは同じではありません。
すでにTOTPを使っている人でも、パスキーに変える意味はある？
あります。
特に大きいのは、フィッシング耐性です。
強い固有パスワードを使い、TOTPも設定している人は、すでにかなり良い対策をしています。
それでも、偽サイトへ自分でパスワードとTOTPコードを入力してしまうタイプの攻撃は残ります。
パスキーは、この部分を人間の注意力だけに頼らない仕組みに変えられます。
そのため、
「TOTPまで使っているならパスキーへ移行する意味はほとんどない」
とは言えません。
サービスが正式にパスキーへ対応しているなら、安全性の面から移行する合理性はあります。
一方、パスキーに対応していないサービスでTOTPをやめる理由もありません。
パスワード＋TOTPは現在でも有効な防御です。
実際の使い分けとしては、
パスキー対応 → パスキーを使う
パスキー非対応 → 強い固有パスワード＋TOTPを使う
という考え方がシンプルです。
パスキーへ移行した場合も、端末の画面ロックやクラウドアカウント、復旧メールなどは引き続き重要です。
結局、パスキーは「パスワード＋認証アプリ」より安全？
調べた範囲では、フィッシングや認証情報窃取に対しては、パスキーの方が明確に強いと言ってよさそうです。
TOTPの6桁コードは有効な第二要素ですが、人間が読んで偽サイトへ入力できるという限界があります。
パスキーでは、認証情報を正規サイトへ結び付けることで、その種類の攻撃を仕組み自体で防ぎやすくしています。
ただし、パスキーはアカウント全体を無敵にする仕組みではありません。
結論としては、
すでにTOTPを使っている人でも、対応サービスならパスキーへ移行する安全上の意味はある。
そして、
パスキーが使えないサービスでは、パスワード＋TOTPは今でも十分価値のある対策です。
パスキーは「今までの安全対策を全部不要にするもの」ではなく、特にフィッシングに対して、認証を一段強くする仕組みと考えるのが一番近いでしょう。
主な参考資料
NIST Special Publication 800-63B — Authentication and Authenticator Management
https://pages.nist.gov/800-63-4/sp800-63b.html
W3C — Web Authentication: An API for accessing Public Key Credentials Level 2
https://www.w3.org/TR/webauthn-2/
Google for Developers — Passkeys
https://developers.google.com/identity/passkeys
Microsoft Threat Intelligence — From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud
https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/
Google Security Blog — Protecting Cookies with Device Bound Session Credentials
https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/
CISA — Implementing Phishing-Resistant MFA
https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf
コメント