この記事では、パスキーが万能ではない3つの理由を説明します。読者にはIT技術者を想定していますが、あまり経験のないエンジニアであっても読めるようにするつもりです。
Attestationによるユーザーの自由とプライバシーの侵害
パスキーにはattestationという、認証器を特定するための仕様が備わっています。ここで認証器とは、パスキーの実装を提供する実装のことです。例えば、Chromeに内蔵されたGoogle Password Managerや、AppleのTouchIDとKeyChain、あるいはBitWardenのようなパスキーをサポートするパスワードマネージャーなどです。この仕組みを使って、Webサービスはユーザーが何を使ってパスキーを使用しているのかを特定することができます。
これが問題な理由は、Webサービスが、ユーザーが使用できる認証器を一方的に制限することができるからです。
例えば、あなたはA銀行のネットバンキングを利用したいとします。あなたはPというパスワードマネージャーを使用しており、A銀行へログインするとき、Pを使用したいと考えています。しかし、A銀行はPのライバルであるQパスワードマネージャーに出資していました。そこで、自社のサービスに、Pの利用を禁止させる、ということができてしまいます。あるいは単に「フリーソフトウェアは危険だから、使わせない」として、フリーソフトウェアのパスキー実装の使用を禁止する、などのことも起こり得ます。さらには、特定の認証機器の強制が、監視・検閲インフラと結びつくリスクすらあります。
一言でまとめると、サービス提供側が、ユーザーがどのように秘密情報を管理するかという権利を奪うことができるのです。
公平のために書いておくと、現在のChromeやSafariの実装は、認証器情報を提供しません。仕様上でも、none(認証器情報を提供しない)が推奨されています。そのため、上記で書いたようなシナリオを実行することは、現在は不可能です。しかし、「そうする能力はあるが、今はしていない」というのは、余り説得力のある反論ではないでしょう。パスキーが普及したあとから使い始めるということは、想像に難くありません。
パスキーは認証情報のバックアップを難しくする
複数のデバイスで一つのWebサービスアクセスするとき、パスキーでは、各デバイスで秘密鍵を持つのが一般的です(「デバイスバインド」と呼ばれる)。例えば、スマートフォンの指紋認証のような、ハードウェアの認証器を利用しているケースなどです。この場合、ユーザーは秘密鍵を他のデバイスに移動したり、バックアップしたりすることが出来なくなります。
パスキーを複数のデバイスで利用する場合、それぞれのデバイスで別の秘密鍵を使うのが一般的です。そのため、新しいデバイスでログインをするときには、すでに認証済みの古いデバイスを持っていることが必須になります。そのため、古いデバイスへアクセスできなくなった場合、アカウントの復旧がとても難しくなります。スマホを落としたり、あるいは旅行中で古いスマホがない場合、機種変更で新しいスマホをセットアップする前に古いものを削除してしまった場合などに、ログインが困難になります。
この問題の簡単な解決策は、秘密鍵を共有できるパスワードマネージャーを使うことです。しかし、各Webサービスはsynced実装を許すかどうかを選択できます。どうしてもバックアップできないということが起こり得ます。
このパスキーの設計を擁護する人たちは、バックアップが出来ないようにするのは意図的であり、ユーザーの安全を守るためだ(バックアップを利用して鍵を盗み出すことへの対策)と主張します。しかし、ユーザーが自分の情報をどう管理するかは究極的にはユーザーが決めることであり、サービスがユーザーの選択へ、パターナリスティックに干渉するべきではありません。言い換えれば、「多少危険であっても利便性を選択する」のはユーザーの権利です。
フィッシング耐性に対する過大評価
FIDOアライアンスは「パスキーはフィッシング耐性があり安全であるようデザインされている」と書いています1。パスキーは“認証情報窃取型”フィッシングに強い⼀⽅で、詐欺全般や不正送⾦誘導を防ぐ銀の弾丸ではありません。パスキーを使っているからといって、フィッシングに絶対に引っかからなくなるということはありません。
パスキーにフィッシング耐性があるとされるのは、パスキーがドメインに対して紐づくためです。パスワードマネージャーを使っている場合もドメインと紐づいて入力補完が行われますが、手動でコピーアンドペーストすることができるため、違うドメインに手動入力してしまう可能性があるため、パスキーよりも弱いとされています(パスキーはAPI経由なのでユーザーがさわれず、そのような危険はない)。後述するトロイ・ハント氏の例がそうです。
一見すればこれは正しいように見えるかもしれませんが、それはフィッシングの目的を「認証情報を盗み取ること」と見誤っています。確かにパスキーの場合認証情報を盗むのが難しくなるのは事実ですが(不可能ではない2)、他の手段はいくらでも存在します。
具体的な手法の一例を説明します。例えば、DOMを使って、パスキー認証そっくりの画面を作ることが出来ます。ユーザーは、自分ではブラウザーのパスキーを操作しているように思っても、実際にはWebページ内のDOMを操作しているのです。
画像引用元: https://developers.googleblog.com/ja/designing-the-user-experience-of-passkeys-on-google-accounts/
上記は本物のパスキーの実装ですが、「DOMを使い、本物らしく見せかけた画面を作る」ということです。そうして、ユーザーに、本物のページにログインしたと思い込ませることが出来ます。あとは適当に、「決済情報が無効なので、クレジットカードを入力し直してください」などと表示すればよいのです。これは、「browser in the brower」と呼ばれるタイプの攻撃の変種です。
このシナリオにはいくつか反論が予想されるので、やや脱線しますが、再反論を記載しておきます。
- ユーザーがChromeを(あるいは特定のパスキー実装を)使っているとどうして分かるのか? => 分かる必要はない。多くのユーザーが使っている実装を真似れば、「誰かは」それを使っている。また、標的型攻撃であれば、あらかじめ対象が何を使っているのか調べることができる
- ユーザー名が表示されるので、そこで見分けることができる => これはユーザーが表示内容を注意深く確認することを前提としている。また、標的型攻撃であれば、それらしいユーザー名を表示することができる
- 認証情報を盗めるわけではない => これはその通り。だが、フィッシングは認証情報を盗むことだけではない。認証情報を盗めなくても、いくらでもユーザーに危害を加えることができる(上記シナリオはその一例)
こうした問題は「ユーザーが注意していれば防げるのでは?」と思われるかもしれません。しかし、この議論はパスワードに対して繰り返し向けられてきた批判と同じです(「注意すればメールアドレスがおかしいことに気づく」「注意すればドメインが間違っていることに気づく」etc)。
最大の問題点は、「パスキーを使っていればフィッシングに引っかからない! 安全だ!」という間違った印象を与えることにあります。〇〇していれば安全だ、という教育は、容易にそれを逆手に取って攻撃に利用することが出来ます。社会工学的な問題を技術的に解決しようとするのが、そもそも間違っているのです。
余談ですが、同様の問題はBIMI(メールの受取人にアイコンを表示する規格)にも存在します。具体的な名前は上げませんが、多くの会社が、「アイコンが表示されれば正しいメッセージです」という旨のメッセージを発信しています。攻撃者は似たようなアイコンを取得するだけでしょう。ここでもまた、「ユーザーが注意していれば防げる」問題です。
パスキーの利点
パスキーには、パスワードに変わる技術的な利点があることは事実なので、それについて触れないのはフェアでないでしょう。
公開鍵による認証
第一に、やり取りされる秘密情報はチャレンジレスポンスになるので、中間者攻撃への耐性が向上します。
第二に、サービス側に秘密情報を保存しない(公開鍵を登録するだけ)なので、サービスがパスワードを漏洩するリスクがなくなります。パスワードを平文保存している会社は未だに多くありますし、ハッシュ化したとしても、ソルトなどが不適切でレインボーテーブルで攻撃されるリスクは無視できません。パスキーにはそうしたリスクがありません。
これらはパスキーが明確にパスワードよりも優れている点です。
フィッシング耐性
「さっきと言っていることが違うじゃないか」と思われるでしょうが、パスキーがフィッシング耐性を向上させるのは間違いありません。最近では、著名なセキュリティー研究者であるトロイ・ハントがフィッシング詐欺に引っかかったことが話題になりました。このようなケースは認証情報を奪うことを前提にした攻撃であるため、パスキーであれば防げたケースです。一方で、私の率直な意見を書かせていただければ、パスキーが実装されていればすべてのフィッシングが防げるように書くのは不誠実であると思います。これは「不注意」が原因で起こった事故であることをご本人も認めており、そして「不注意」はパスキーでは防げないからです。
これは、ある「フィッシング対策手法」が確立されると、「それを利用した詐欺手法」が生まれる、という、ある種のいたちごっこのようなものです。「不注意」は注意することのみで防げる、という他ないでしょう。残念ながら、この問題に銀の弾丸はなく、パスキーは銀の弾丸ではありません。そうでないものをそうであるかのように宣伝することは、むしろそれを利用した詐欺に有利に働くだけでしょう。このような間違った宣伝は、むしろフィッシングの危険性を高めています。
パスキーがだめなら、じゃあどうすればいいの?
パスキーの問題点はプライバシーを侵害する機能が含まれていることであって、公開鍵認証が共有パスワードに対して優位点があるのは事実です。また、多くのユーザーがパスワードを適切に管理しておらず、非常に危険な使い方をしていることも認めざるを得ません(パスワード使いまわし、脆弱なパスワード、etc)。しかしそれはユーザーの選択の結果であり、それを理由に、プライバシー上の問題がある規格の導入が強制されていっているという状況はやはり認められません。
もしプライバシーの問題がなくなり、ユーザーの自由な選択が許されるようになるとすれば、パスキー(の新しい代替)に移行していくことは望ましいと思います。
まとめ
パスキーが万能ではない理由は、
- 認証器の制限を利用した、プライバシーの侵害
- 秘密鍵のバックアップが制限されること
- パスキーを使っていれば絶対にフィッシングに引っかからないという、間違った認識を広めている
点です。
私は公開鍵を利用したWebサービスの認証自体に反対ではありません。Attestationを排除し、バックアップの権利を認め、フィッシング詐欺に対する間違った啓蒙をやめ、ユーザーの権利を尊重するものに生まれ変わってほしいと思います。
余談
悪意のあるプログラムの話
私が見かけたパスキーへの批判の一つに、ユーザーが悪意のあるプログラムをダウンロード・実行するなどして、パスキーの秘密鍵自体が盗まれた場合、安全ではないというものがありました。まあそれはそうかもしれないですが、そこまで行くともう何も安全ではないので、個人的にはあまり上手い議論ではないかなと思います。とはいえ多くのエンジニアはセキュリティーというものを全く気にしていないので(よく知らないnpmのパッケージをインストールするとか、AIエージェントを --dangerously-skip-permissions で動かすとか)、パスキーのストレージを盗み出すというのも全く現実的でないとは言えないのかもしれません、
UXの話
本記事では、よくパスキーの不満として挙げられるUX面については特に触れませんでした。確かに現状のパスキーの実装はあまり直感的とは言い難いものが多いように感じますが、これは努力と時間によって解決されるであろうと思えます。世の中には酷いパスワード実装がいくらでもあるので、UXをもってパスキーの欠点とするのは不公平かと思い、ここでは取り上げませんでした。
AIの話
最初にこの記事を書いたときは100%AIフリーだったが、AIによるリライトで、だいぶ何が言いたいのかわからないものになってしまった。何も出さないよりは良いと思って公開したが、論点がぶれて分かりづらいと思った人がいたら申し訳なく思う。タイトルからして意味不明だ。
この記事はあくまで私個人の名前で個人の責任で書いたものだし、所属会社の名前を出したわけでもなかった。しかし、過去に会社のアドベントカレンダーにこのアカウントで参加したため、特定の可能性があるということで、依然として「炎上対策」が必要であるということであった。そこで、ChatGPTの指示に従い、いくつかの箇所を削除したり書き換えた。
新しい現象なのは、こうした「添削」が、AIによって実行されることである。星新一のショートショート「肩の上の秘書」がこのような事態を予見していたことは、もうすでに多くの人が指摘している。
そういう時代になったということだろう。
この件については、別の記事を書いてみたい。