はじめに
弊社の代表から、セキュリティの高いログイン方式であるパスキーについて学んでほしい、と声がかかりました。セキュリティへの意識が高い会社として、取り組みを外にも伝えていきたいという話もありました。
私はそれまで、パスキーの存在は知っていたものの、どういうものかを知りませんでした。そこで仕組みを調べて、社内の tips 共有会で発表をしました。
この記事ではそのときのスライドを使ってパスキーの仕組みを説明します。既存のログイン方式とどう違うのか、登録とログインで何が起きているのか、なぜ偽サイトに強いのかが分かります。
ログイン方式の早見表
先に、調べた結果を表で見せます。6 つのログイン方式を、フィッシングに強いか、サーバーから漏れたときにどうなるか、ユーザーの手間、実装の手間の 4 つの観点で比べました。
上の 5 行が既存の方式で、いちばん下がパスキーです。パスキーが既存の方式より強いのは、フィッシングと漏えいの 2 列です。代わりに、実装の手間の列には「復旧の手段を設計する」が残ります。理由はこのあとの節で順に見ていきます。
米国 NIST の認証ガイドライン SP 800-63B-4 も、TOTP や SMS のようにコードを手で入力する方式を、フィッシングに強い方式（phishing-resistant）とは見なしていません。メールについては、そもそも認証に使ってはならないとしています。
ユーザーの手間の列は導入した会社の数字にも表れています。認証の業界団体 FIDO Alliance が 2025 年 10 月に公開した「Passkey Index」には、Amazon、Google、Microsoft、LINE ヤフー、メルカリ、NTT ドコモなど 9 社の調査の結果が載っています。
ログインの成功率は、パスキーが 93%、ほかの方式が 63% でした。1 回のログインにかかる時間は、パスキーが 8.5 秒、従来の MFA が 31.2 秒です。どちらも、参加した各社が調査に答えた値を FIDO Alliance と調査会社の Liminal がまとめたものです。
既存の方式の弱いところ
今あるログイン方式を並べると、上の 6 つになります。いちばん長く使われているのが ID とパスワードです。パスワードに足す形でよく使われるのが、SMS で届くコードと、認証アプリに出る 6 桁のコード（TOTP）です。
パスワードを持たない方式もあります。メールに届いたコードを入れるメール OTP と、メールに届いたリンクを開くだけのマジックリンク、Google などのアカウントでログインするソーシャルログインです。
どの方式にも弱いところがあります。パスワードの弱いところは 3 つです。
- 偽サイトに自分で入力してしまう
- サーバーから漏れる。ハッシュ化していても、短いパスワードは総当たりで元に戻せる
- 使い回される。1 か所で漏れると、同じパスワードを使うほかのサービスにも入られる
コードを入力する方式はパスワードに足しても突破されることがあります。偽サイトがコードをその場で本物のサイトに中継する手口で、リアルタイムフィッシングと呼ばれます。
マジックリンクとソーシャルログインはパスワードを持ちません。ただ、ログインの安全さはメールや Google などのアカウントの強さで決まります。マジックリンクには、メールのセキュリティ製品が先にリンクを開くと、本人が開いたときには使えなくなる問題もあります。
こうした弱いところに強い方式として出てきたのが、パスキーです。パスキーは偽サイト・漏えい・使い回しを、ユーザーの注意ではなく仕組みで防ぎます。
パスキーの仕組み
端末にある鍵で本人確認する
パスキーはパスワードの代わりに端末にある鍵で本人確認するログイン方式です。
鍵は秘密鍵と公開鍵の 2 本で 1 組です。秘密鍵で作った署名は対になる公開鍵で検証します。スライドの 3 つの項目は次のことを指しています。
- 秘密鍵はサーバーに送らない。署名は端末の中で作る
- サーバーが持つのは公開鍵だけ。公開鍵では署名を作れないので、漏れてもログインには使えない
- 鍵はサイトごとに作る。ほかのサイトでは使えないので、使い回しが起きない
指紋や顔はサーバーに送らない
「指紋をサーバーに登録するの？」は、よく誤解されるところです。答えは「登録しない」です。
指紋や顔の照合は端末の中で終わります。本人だと分かると、端末が秘密鍵の使用を許可して署名を作ります。サーバーに届くのは、署名と、本人確認をしたかどうかのフラグです。生体情報は端末の外に出ません。
登録とログインの流れ
ここからは、Mac の Chrome で Google アカウントにパスキーを登録し、ログインする場合を例に流れを追います。
登場するのは端末、ブラウザ、サーバーの 3 つです。パスキーが使っている Web 標準の WebAuthn では、サーバーのことを Relying Party、略して RP と呼びます。流れは W3C の仕様のほか、Google の開発者向けサイト web.dev の記事「Create a passkey for passwordless logins」と、開発者向けの解説サイト passkeys.dev を参考にしました。
まず登録です。
- ログイン済みのユーザーが「パスキーを登録」を押す
- サーバーが challenge（使い捨ての乱数）、RP ID（サイトのドメイン。Google なら google.com）、user.id（アカウントごとの ID）を返す
- ブラウザが
navigator.credentials.create()を呼ぶ。このとき、開いているページの origin が RP ID と合っているかを、ブラウザが確かめる - ユーザーがパスキーの保存先を選ぶ。Mac の Chrome なら iCloud キーチェーンや、入れていれば 1Password などのパスワードマネージャー
- 端末が指紋や顔で本人確認をして、このサイト専用の鍵ペアを作る。秘密鍵は端末に残る
- 端末からブラウザに、公開鍵と credential ID が返る
- ブラウザが公開鍵と credential ID に clientDataJSON を足してサーバーに送る。clientDataJSON はブラウザが書くデータで、origin と challenge が入っている
- サーバーが、challenge と origin が自分の出したものかを確かめてから、公開鍵を保存する
4 の保存先によって、あとで鍵が同期される端末が変わります。どの手順でも、秘密鍵は端末の外に出ていません。
次にログインです。形は登録とほぼ同じです。
- ユーザーがログインボタンを押す
- サーバーが challenge と RP ID を返す。challenge は毎回変わるので、前回の署名を使い回す攻撃は通らない
- ブラウザが
navigator.credentials.get()を呼ぶ。候補になるのは、この RP ID で作られた鍵だけ - 候補が複数あれば、どのアカウントのパスキーを使うかをユーザーが選ぶ
- 端末が本人確認をして、challenge を含むデータに秘密鍵で署名する
- 端末からブラウザに、署名と authenticatorData、credential ID が返る。authenticatorData は端末が書くデータで、RP ID のハッシュと、本人確認をしたかどうかのフラグが入っている
- ブラウザが自分で書いた clientDataJSON を足してサーバーに送る
- サーバーが credential ID で登録時の公開鍵を探し、署名を検証する。challenge と origin も確かめ、正しければログインが成功する
サーバーが持っているのは公開鍵だけです。そのため、DB が漏れても、それを使ってログインはできません。
実例で見る偽サイトでの違い
amazon.com の先頭の a を、キリル文字の а（U+0430）に替えた偽ドメインは、X で話題になりました（Polymarket Japan の X の投稿）。英字とそっくりなキリル文字はほかにもいくつもあり（A2CBoston の X の投稿）、見た目だけで見分けるのは不可能です。
Chrome は、英字とキリル文字が混ざったドメインを、URL バーでは xn-- から始まる形で表示します（Chromium のドキュメント「IDN in Google Chrome」）。それでも、メール本文のリンクの文字では見分けられません。
この偽サイトにパスキーでログインしようとすると、どうなるかを見ます。
左が本物の amazon.com、右がキリル文字の а を使った偽サイトです。
本物のサイトでは、ブラウザがこのドメインのパスキーを候補に出し、ログインできます。偽サイトでは RP ID が一致しないので、パスキーは候補にすら出ません。ブラウザは見た目ではなく文字のコードで比べるため、U+0430 の а と U+0061 の a は別の文字として扱われます。ユーザーが騙されていても署名が作られないので、偽サイトが本物のサイトに中継することもできません。
パスワードでは、偽物を見分けるのは人間の目です。パスキーでは、ブラウザがドメインを機械的に比べます。ここが、パスキーと既存の方式のいちばん大きな違いです。
同期するパスキーとしないパスキー
ここまでの仕組みは、パスキーという名前が付く前からありました。
- 2013 年: パスワードに頼るのを減らすための業界団体 FIDO Alliance が発表される（設立は 2012 年）
- 2014 年: 最初の FIDO の規格 U2F・UAF が出る。U2F はセキュリティキーを 2 要素目に使い、UAF は端末の指紋などでパスワードなしにログインする
- 2019 年: Web の標準を決める W3C が WebAuthn を正式な標準にする。ブラウザから、パスワードを使わずに秘密鍵の署名でログインできるようになった
- 2022 年: Apple・Google・Microsoft が、鍵を端末のあいだで同期できるようにすると共同で発表
偽サイトに強い仕組みは 2019 年の時点でそろっていました。ただ、鍵は作った端末から出られませんでした。新しい端末にするとサービスごとに登録し直しになり、端末をなくすと、その鍵ではログインできません。会社の中なら管理ツールで対応できても、一般のユーザーには広まりませんでした。
そこで 2022 年に、鍵を端末のあいだで同期できるようにする発表がありました。この同期できる鍵が、パスキーと呼ばれ始めました。いまは、端末から出ない鍵も含めてパスキーと呼びます。仕組みは前からあり、それを使いやすくしたのがパスキーです。名前が付いたのは 2022 年と知って、パスキーは結構最近のものなんだなと思いました。
いまのパスキーには 2 種類あります。
同期するパスキーは、スマホで作ると、iCloud キーチェーンや Google パスワードマネージャー、1Password を通して、同じアカウントのほかの端末にもコピーされます。年表の 2022 年の同期がこれです。端末をなくしても、別の端末でログインできます。
端末から出ないパスキーは、YubiKey のようなセキュリティキーの中で作る鍵です。秘密鍵を外にコピーできないぶん安全ですが、なくしたら、その鍵ではもうログインできません。サーバー側では、認証器が返すフラグで、どちらのパスキーかを見分けられます。
おまけ: パスキーの弱いところ
パスキーのいちばん大きな弱いところは復旧です。
スマホをなくした本人は「ログインできない方」から、メールに届いた復旧リンクを開きます。新しい端末でパスキーを作り直せば、またログインできます。
ところが、本人のメールを乗っ取った攻撃者も、まったく同じ入口を通れます。パスキー自体がフィッシングや漏えいに強くても、アカウントの強さは復旧手段の強さまで下がります。復旧が SMS なら、SMS と同じ強さです。
対策は 2 つです。
- パスキーを 2 つ以上登録してもらう。スマホをなくしても PC のパスキーで入れるので、復旧の入口を使わずに済む
- 復旧したら本人に通知する。攻撃者が復旧しても、本人の端末やメールに通知が届けば、本人が気づける
どちらも NIST SP 800-63B-4 に書かれています。2 つ以上の認証手段を持つよう利用者に勧めること（SHOULD）と、復旧したら本人に通知すること（SHALL）です。
もう 1 つは、OS をまたぐときです。iPhone で作ったパスキーは、iCloud キーチェーンで、同じ Apple アカウントの Mac や iPad に同期されます。一方で、Windows の PC ではそのまま候補に出ないことがあります。対応の状況は、OS やバージョンしだいです。
その場合は、PC に出る QR コードをスマホで読み、スマホのパスキーでログインします。スマホが近くにあることが前提です。1Password のような、OS を問わないパスワードマネージャーにパスキーを保存する方法もあります。
利用者の端末の事情によっては、パスキーだけにせず、別のログイン手段を残すことも考える必要があります。
最後に
パスキーは、端末にある秘密鍵で署名し、サーバーが公開鍵で確かめるログイン方式です。ブラウザがドメインを比べるので、偽サイトでは鍵が候補に出ません。サーバーから公開鍵が漏れても、ログインには使えません。
代表に声をかけてもらうまで、私はパスキーの概念を知りませんでした。調べてみると、仕組みは 2019 年からあり、それを使いやすくしたのがパスキーでした。
自分のサービスにパスキーを足すときは、どの画面でパスキーの作成を案内するかと、端末をなくした人をどう復旧させるかを先に考えてみてください。
参考文献
- 仕様
- 解説
- 歴史
- FIDO Alliance「Charting an Accelerated Path Forward for Passwordless Authentication Adoption」2022 年 3 月 17 日
- Apple Newsroom「Apple, Google and Microsoft commit to expanded support for FIDO standard to accelerate availability of passwordless sign-ins」2022 年 5 月 5 日
- 数字
- FIDO Alliance「Passkey Index」2025 年 10 月
- そっくりな文字の偽ドメイン
- Polymarket Japan の X の投稿（Amazon そっくりの偽 URL）
- A2CBoston の X の投稿（英字とそっくりなキリル文字）
- Chromium のドキュメント「IDN in Google Chrome」
株式会社シンシア
株式会社シンシアでは、実務未経験のエンジニアの方や学生エンジニアインターンを採用し一緒に働いています。
※ シンシアにおける働き方の様子はこちら
弊社には年間100人以上の実務未経験の方に応募いただき、技術面接を実施しております。
この記事が少しでも学びになったという方は、ぜひ wantedly のストーリーもご覧いただけるととても嬉しいです！