パスキーの仕組みパスワードは漏れると使い回され、パスキーは漏れても使えない理由

ハッシュ関数 (hash function) は、入力から決まった長さの値を計算する関数で、同じ入力からは必ず同じ値が出て、出た値から入力を逆算することはできません。サービスはパスワードの代わりにハッシュ値を保存し、ログインのたびに入力をハッシュ化して保存値と比べます。こうすれば、保存データを見てもパスワードそのものは分かりません。

ところが攻撃者は逆算する必要がありません。よく使われるパスワードの一覧（辞書）を用意し、1 つずつハッシュ化して、漏れた値と同じものを探せば済みます。SHA-256 は速く計算できるように作られた関数で、ゲーム用の GPU 1 台で毎秒 200 億回を超える計算ができます。123456 や password1 は、文字どおり一瞬で見つかります。

ソルト (salt) は、利用者ごとに作る乱数で、パスワードにつなげてからハッシュ化します。ソルトが無いと、同じパスワードの利用者は同じハッシュ値になり、1 つ割れれば同じ値の全員が割れます。ソルトがあれば、攻撃者は利用者 1 人ずつ計算をやり直すしかありません。

bcrypt・scrypt・Argon2 は、パスワードの保存専用に作られた低速なハッシュ関数で、ソルトを内部に持ち、1 回の計算に意図的に時間をかけます。正しいパスワードで 1 回ログインするには気にならない遅さでも、数十億の候補を試す攻撃者には致命的な遅さになります。

この流れで、サービスの手元に残るのは公開鍵と credential ID だけです。公開鍵でできるのは「この署名は、ペアの秘密鍵で作られたか」を確かめることだけで、署名を作ることはできません。パスキーで広く使われる楕円曲線暗号 ECDSA P-256 では、公開鍵から秘密鍵を求める計算に、現在の計算機を総動員しても宇宙の年齢を大きく超える時間がかかります。

チャレンジが毎回変わることにも意味があります。通信を盗み見て署名を記録しても、その署名は記録した回のチャレンジに対するもので、次のログインでは別のチャレンジが来るため使えません。紙の書類に押した印影をコピーしても、次の書類には使えないのと同じです。

鍵ペアはサービスごとに別々に作られます。サービス A に登録した公開鍵は、サービス B のどこにも登録されていません。パスワードの使い回しにあたるものが、仕組みの上で起こりません。

03 で見たとおり、パスキーは登録したサイトのドメインに結びついています。偽サイト examp1e.jp（l の代わりに数字の 1）でログインしようとしても、ブラウザはそのドメイン用のパスキーを持っていないので、候補自体が出ません。利用者が偽サイトだと気付かなくても、渡すものがありません。

パスワードでは、偽サイトかどうかを見分けるのは人間です。アドレスバーの 1 文字の違いを見落とした時点で、入力したパスワードは攻撃者に渡ります。パスキーでは、ドメインの照合をブラウザが行います。利用者の注意力に頼らないことが、パスキーがフィッシングに強いと言われる理由です。

SMS や認証アプリの 6 桁のワンタイムパスワードを組み合わせる二要素認証も、偽サイトには破られます。偽サイトがパスワードと 6 桁のコードを受け取り、有効期限の 30 秒ほどのうちに本物のサイトへ転送してログインする手口で、リアルタイムフィッシングと呼ばれます。パスキーの署名には相手のドメインが含まれるので、偽サイトが受け取った署名を本物へ転送しても検証に通りません。

パスキーを登録していないパソコンでログインするときは、パソコンの画面に出る QR コードをスマートフォンで読み取り、スマートフォンのパスキーで署名する方法が使えます。このとき、パソコンとスマートフォンが Bluetooth で互いに近くにあることを確かめるので、離れた場所にいる攻撃者が QR コードを写真で送ってきても、それを読み取ってログインさせられることはありません。

端末の中で秘密鍵を守るのは、iPhone や Mac の Secure Enclave、Windows パソコンの TPM のような、OS からも中身を直接読めない専用の領域です。秘密鍵を取り出すには、端末の画面ロックを解除できることが前提になります。

サービスを運営する側は、次の 3 点を確かめましょう。

1 つ目は、今のパスワードの保存方式です。平文や、元に戻せる暗号化、ソルトの無いハッシュ値で保存しているなら、パスキーの導入より先に是正の対象です。次に利用者がログインしたときに、入力されたパスワードを Argon2id か bcrypt で保存し直す形で移行できます。

2 つ目は、パスキーを登録した利用者が、パスワードを削除できるかです。パスキーを追加してもパスワードのログインが残るなら、利用者にとっての攻撃口は減っていません。パスキーの登録後にパスワードを削除する選択肢を用意します。

3 つ目は、復旧手段がパスキーより弱い入口になっていないかです。メール 1 通で誰でもパスキーを登録し直せる作りなら、攻撃者はそこを通ります。復旧のときに、登録済みの別のパスキーや、本人確認書類の確認を求める段を設けます。

パスキーを保存するテーブルには、ヒーローのテーブルのように credential ID・公開鍵・sign_count を利用者ごとに複数行持たせます。1 人が複数の端末やセキュリティキーを登録するので、利用者と鍵は 1 対多になります。