🔑

パスワードが必要なパスキーとそうでないパスキーは何が違う?どうして違う?

はじめに

「パスキーを使うときにパスワードが求められるときと、求められないときがあるのはなぜ?」パスキーを使い始めると、こんなことに気づきます。

あるサービスでは、ログイン画面でパスキーを選ぶだけで、何も聞かれずにログインが完了します。ところが別のサービスでは、パスキーを選んだあとに毎回Face IDや指紋認証、あるいはPINの入力を求められます。

先に答えを言ってしまうと、これは不具合でも実装ミスでもなく、サービス側がわざと選んでいる設定の違いです。この記事では、その違いが何なのか、どうしてサービスによって違うのかを、細かい仕様には立ち入らずにざっくり説明します。

パスキーがやっていることをざっくり知る

まず、パスキーがログイン時に何をしているのかを、たとえ話で押さえます。

パスキーを登録すると、スマホやPCの中に鍵のペアが作られます。片方は秘密の鍵で、サービス側には渡りません。もう片方は錠前のようなもので、こちらだけがサービス側に渡されます。

ログインのとき、サービスは「この錠前に合う鍵を持っていますか?」という確認をしてきます。スマホの中の秘密の鍵がそれに応えられれば、ログイン成功です。

sequenceDiagram
    participant P as スマホ(秘密の鍵)
    participant S as サービス(錠前)

    Note over P,S: 登録のとき
    P->>P: 鍵のペアを作る
    P->>S: 錠前だけを渡す

    Note over P,S: ログインのとき
    S->>P: この錠前に合う鍵を持っていますか?
    P->>P: 秘密の鍵で応える
    P->>S: 応答を送る
    S->>S: 錠前と照合してOKならログイン成功

ポイントは、サービス側に渡っているのが錠前だけだということです。パスワードのようにサービス側から漏れて悪用される秘密がそもそも存在しません。また、この確認のやりとりは本物のサービスとの間でしか成立しないようにできているため、偽サイトに誘導してパスワードを打たせるようなフィッシング詐欺も通用しません。パスキーが安全と言われるのはこのためです。

「持っている」と「本人である」は別の話

ここからが本題です。さっきの流れで、サービス側が確認できたことをよく考えてみます。

秘密の鍵が応えてくれたということは、「登録したスマホがそこにある」ことは確認できました。でも、そのスマホを操作しているのが誰かまでは分かりません。持ち主本人かもしれないし、スマホを拾った(あるいは盗んだ)別の誰かかもしれません。

家の鍵にたとえると分かりやすいです。鍵を持っている人は家に入れますが、鍵を持っているからといって家主本人とは限りません。

  • 持っていることの確認: 登録したスマホ(秘密の鍵)がそこにある
  • 本人であることの確認: そのスマホを操作しているのが持ち主本人である

この2つは別物で、パスキーの仕組みでは分けて扱われています。そして、Face IDやPINが担当しているのは後者、つまり「操作しているのがスマホの持ち主本人か」の確認です。だから入力を求められるのはサービスのパスワードではなく、スマホのロック解除と同じ手段なのです。スマホのロックを解除できる人はスマホの持ち主本人だろう、という理屈です。

違いの正体: 本人確認を求めるかどうかをサービスが選んでいる

そして、この本人確認をやるかどうかは、ログインのたびにサービス側が指定できます。パスキーの土台であるWebAuthnという仕様に、User Verification(ユーザー検証)という設定があり、サービスは大きく次の3つから選べます。

  • 必須(required): 必ず本人確認する。Face IDやPINが毎回求められる
  • できれば(preferred): 端末が対応していれば本人確認する。指定しなかった場合の標準もこれ
  • 不要(discouraged): 本人確認は省略して、スマホがあることの確認だけで通す

つまり冒頭の疑問の答えはこうです。Face IDやPINを求めてくるサービスは「スマホがあるだけじゃなく、本人が操作していることまで確認したい」という設定を選んでいて、何も聞かれないサービスは「スマホがあることの確認だけで十分」という設定を選んでいます。

なお、スマホには端末側の事情もあります。サービスが不要と言っていても、iPhoneなどはパスキー使用のたびにFace IDやパスコードを求めてきます。何も聞かれないログインが起きやすいのは、実際にはセキュリティキーやPCのブラウザ環境です。

フローで見比べると、違いは一目瞭然です。本人確認ありの場合はこうなります。

sequenceDiagram
    participant U as あなた
    participant P as スマホ
    participant S as サービス

    S->>P: 鍵の確認をお願いします(本人確認: 必須)
    P->>U: Face ID・指紋・PINをどうぞ
    U->>P: ロック解除と同じ操作をする
    P->>S: 「鍵もあるし、本人でした」と応答
    S->>S: 確認してログイン成功

本人確認なしの場合は、真ん中のステップが丸ごと消えます。

sequenceDiagram
    participant U as あなた
    participant P as スマホ
    participant S as サービス

    S->>P: 鍵の確認をお願いします(本人確認: 不要)
    P->>S: 「鍵はあります」と応答
    S->>S: 確認してログイン成功

違いはこれだけです。パスキーそのものが2種類あるわけではなく、同じパスキーでも、サービスがどちらの確認まで求めるかで体験が変わります。

どうして違う?: サービスごとの事情

では、なぜサービスによって選択が分かれるのでしょうか。これはセキュリティと使いやすさのトレードオフです。

本人確認を必須にすると、スマホごと盗まれても、Face IDやPINを突破されない限りログインされません。その代わり、ユーザーは毎回ひと手間かかります。銀行や決済サービスのように、突破されたときの被害が大きいサービスはこちらを選びます。ログインは軽くしておいて、送金や設定変更のような重要な操作の直前にだけ本人確認を挟む、という使い分けもよく行われます。

一方、本人確認を省略すると、タップひとつでログインできる快適さが手に入ります。その代わり、スマホやセキュリティキーを物理的に奪われた場合はそれだけでログインされてしまいます。とはいえ、パスキーの強みであるフィッシング耐性は本人確認なしでも保たれるので、ネット越しの攻撃には依然として強いままです。被害が小さいサービスや、パスワードと組み合わせた2段階認証の2段階目として使う場合には、この割り切りが合理的になります。

まとめると、こういう判断でサービスは設定を選んでいます。

  • 守っているものが大きい(お金・個人情報)ほど、本人確認を求める方向へ
  • 毎日のように使うサービスほど、手間を減らす方向へ
  • 心配している相手がネット越しの攻撃者だけなら省略もあり。スマホの盗難まで心配するなら本人確認を

まとめ

  • パスキーのログインで確認されることには「登録した端末を持っている」と「操作しているのが本人」の2段階がある
  • Face IDやPINは後者の本人確認で、入力しているのはサービスのパスワードではなく端末のロック解除手段
  • 本人確認まで求めるかどうかはサービス側が設定で選んでおり、これが「PINが必要なパスキー」と「そうでないパスキー」の正体
  • 求めるサービスは安全側に、求めないサービスは快適さ側に倒しているだけで、どちらも仕様どおりの動き

これでサイトによってパスキー使用時の初動が違うことを理解できました。

参考文献

https://product.st.inc/entry/2024/12/25/000233

新着記事

関連ネットワーク(beta)

ドラッグで移動 / Ctrl+ホイールでズーム