パスワードとパスキーの違い

はじめに

「パスワードはめんどくさい」——多くの人が日々感じているこの不満は、実は根深いセキュリティ上の問題を示しています。複雑なパスワードを覚えることが難しいだけでなく、データ侵害やフィッシング詐欺のリスクにも常にさらされています。そこで登場したのが「パスキー」という新しい認証方式です。本記事では、パスワードとパスキーの根本的な違いを技術的な観点から解説します。

パスワードの本質：共有された秘密の問題点

「共有された秘密」とは何か

パスワードは、サイバーセキュリティの世界で「共有された秘密（shared secret）」と呼ばれています。これは、利用者も利用先のサービスも同じ「秘密」を知っているという意味です。

パスワード認証の仕組み：

1. ユーザーがアカウント作成時にパスワードを設定
2. サービス側がそのパスワードを（暗号化して）保存
3. ログイン時にユーザーが入力したパスワードと保存されたパスワードを照合
4. 一致すれば認証成功

一見シンプルで合理的に見えるこの仕組みですが、実は重大な脆弱性を抱えています。

パスワードが抱える構造的な問題

1. ユーザーの記憶に依存する

複雑で推測困難なパスワードを作成しても、人間がそれを覚えておかなければならないという制約があります。その結果...

• 覚えやすい簡単なパスワードを使ってしまう
• 複数のサービスで同じパスワードを使い回してしまう
• パスワードをメモや安全でない場所に保存してしまう

2. サービス側も秘密を保管している

これがパスワード最大の問題点です。ユーザーだけでなく、サービス提供者側も秘密を保管しているため、ユーザー自身が完全には管理できないのです。

データ侵害のリスク：

• サービス側でデータ侵害が発生すると、パスワードが流出する可能性がある
• 攻撃者が暗号化の解読に少し時間をかければアカウントを乗っ取れる
• ユーザーに何の落ち度がなくても被害に遭ってしまう

実際、セキュリティ対策の甘いサービスでは、侵害時にパスワードが平文のまま流出することさえあり、こうしたことが過去に何度も何度も発生しています。

3. フィッシング詐欺に脆弱

パスワードは盗まれれば悪用できる情報そのものです。攻撃者にとってフィッシング詐欺は常套手段で、偽サイトでパスワードを入力させれば、そのまま本物のサイトで使えてしまいます。

パスキーの本質

公開鍵暗号方式とは

パスキーは、パスワードとは根本的に異なるアプローチを採用しています。それが公開鍵暗号方式です。

共有された秘密を照合する代わりに、公開鍵と秘密鍵というペアを照合する仕組みとなっています。

鍵の役割：

• 公開鍵：誰でも見ることができる鍵。サービス側が保管する
• 秘密鍵：ユーザーだけがアクセスできる鍵。デバイス上にのみ保存される

この二つの鍵は数学的に関連していますが、公開鍵から秘密鍵を推測することは実質的に不可能です。

引用：https://jp.cyberlink.com/faceme/insights/articles/1203/what-is-passkey

なぜ「秘密を共有しない」ことが重要なのか

パスキーの最大の特徴は、秘密がサービス側に渡らないことです。

パスワードとの比較：

項目	パスワード	パスキー
サービス側の保存情報	パスワード（秘密）	公開鍵（秘密ではない）
認証に使う情報	パスワード本体	秘密鍵で作成した署名
データ侵害時の影響	パスワード流出の危険	公開鍵が漏れても被害なし

サービス側が保管するのは公開鍵のみで、この情報自体には何の効力もありません。データ侵害が発生しても、攻撃者が手に入れるのは公開鍵だけで、それではアカウントにアクセスできないのです。

認証プロセスの違いを比較する

パスワード認証の流れ

1. ユーザーがパスワードを入力
2. パスワードがネットワーク経由でサービスに送信される
3. サービス側で保存されているパスワードと照合
4. 一致すれば認証成功

問題点：

• パスワード本体が送信される（盗聴のリスク）
• フィッシングサイトでも同じように入力してしまう
• サービス側で秘密を保管している

パスキー認証の流れ

1. サービスが暗号学的な「チャレンジ」を発行
2. ユーザーのデバイス上で生体認証（指紋、顔認証など）を実行
3. 認証成功後、秘密鍵を使って署名を生成
4. 署名のみをサービスに送信
5. サービス側で公開鍵を使って署名を検証
6. 検証成功で認証完了

重要なポイント：

• 秘密鍵はデバイスから出ない
• 送信されるのは「署名」であり、"秘密"そのものではない
• 認証処理が遠くのサーバーではなく、自分のデバイス上で実行される
• 各チャレンジに対する署名は一度きりで再利用できない

セキュリティ面での決定的な違い

1. フィッシング耐性

パスワードの場合：
偽サイトでパスワードを入力してしまうと、攻撃者はそのパスワードをそのまま本物のサイトで使用できます。

パスキーの場合：
パスキーの署名は特定のサイトのチャレンジに対してのみ有効です。仮に偽サイトで認証を試みても、その署名は本物のサイトでは使えません。公開鍵だけでは何もできないため、被害が発生しないのです。

2. データ侵害への耐性

パスワードの場合：

• サービス側でデータ侵害が発生すると、パスワードが流出する可能性がある
• 暗号化されていても、攻撃者が時間をかければ解読される危険がある
• 平文で保存されている場合、即座に悪用される

パスキーの場合：

• サービス側が保存しているのは公開鍵のみ
• 公開鍵が漏れても、それだけではアカウントにアクセスできない
• 秘密鍵はユーザーのデバイス上にのみ存在する

3. 辞書攻撃・総当たり攻撃への耐性

パスワードの場合：

• よくあるパスワードや辞書の単語を試す「辞書攻撃」が有効
• 文字の組み合わせを順番に試す「総当たり攻撃」も可能
• 短いパスワードや単純なパスワードは特に脆弱

パスキーの場合：

• 秘密鍵は数学的に生成された長大な乱数
• 推測や総当たりは実質的に不可能
• デバイスにアクセスできなければ攻撃自体が成立しない

ユーザー体験の違い

パスワードの使用体験

• 複雑なパスワードを覚える必要がある
• サービスごとに異なるパスワードを管理する必要がある
• パスワードを忘れた場合のリセット手続きが面倒
• 定期的な変更を求められることもある
• 二要素認証を別途設定する必要がある

パスキーの使用体験

• パスワードを覚える必要がない
• 生体認証だけでログインできる
• ユーザー名の入力さえ不要な場合もある
• デバイスを変えても、アカウントに紐付いているため復元可能
• 多要素認証が標準で組み込まれている

例えば、新しいデバイスでGoogleアカウントにサインインしたいとき、パスワードを入力する代わりに、すでに認証済みのスマートフォンを使ってログインすることができます。スマートフォンをパスキーとして使えば、パスワードを入力せずに即座にアクセスできるのです。

パスキーにおける多要素認証

パスキーは一見シンプルに見えますが、実は本質的に多要素認証を利用しています。ただ、それが非常に素早く実行されているので気付きにくいのです。

二重の認証要素

従来の二要素認証（2FA）は、「知っているもの」（パスワード）と「もっているもの」（スマートフォンなど）を組み合わせる仕組みだと説明されます。

パスキーの認証要素：

1. もっているもの：スマートフォンやノートPCなど、秘密鍵を保存したデバイス
2. 自分自身を示すもの：生体認証（指紋、顔認証、PINなど）

パスキーでは、公開鍵と秘密鍵のペアを照合するだけでなく、その秘密鍵を利用できる本人であることも証明する必要があります。その際には多くの場合、生体認証が使われるのです。

FIDOアライアンスのエグゼクティブディレクター兼CEOのアンドリュー・シキアー氏は次のように説明しています。

「サインインの際、サービスは暗号学的なチャレンジを発行します。それに答えられるのは、あなたのデバイス上にある秘密鍵だけです。この秘密鍵は、あなたがもっているもの（スマートフォンやノートPCなど）と、多くの場合はあなた自身を示すもの（生体認証など）によって本人かを証明します。その結果、再利用可能な認証情報が存在せず、フィッシングにも強いログイン方法が実現するのです」

まとめ

パスワードとパスキーの違いは、単なる機能の改善ではなく、認証の根本的なパラダイムシフトです。

核心的な違い

観点	パスワード	パスキー
セキュリティモデル	共有秘密	公開鍵暗号
秘密の保管場所	サーバー側にも保存	デバイスのみ
フィッシング耐性	脆弱	構造的に防御
データ侵害の影響	パスワード流出リスク	公開鍵のみで被害なし
ユーザー負担	記憶と管理が必要	生体認証のみ

パスキーがもたらす価値

セキュリティ面：

• データ侵害の影響を構造的に最小化
• フィッシング攻撃を自動的に防御
• 総当たり攻撃や辞書攻撃が無効

ユーザー体験面：

• パスワードを覚える必要がない
• 生体認証による素早いログイン
• 多要素認証が標準で組み込まれている

パスキーは、「セキュリティとユーザビリティはトレードオフ」という常識を覆し、両方を同時に実現する認証方式だと言われています。Google、Microsoft、Appleなど主要サービスが既に対応しており、今後さらに普及が進むでしょう。

エンジニアとして、この技術的な違いを理解し、適切に実装することが、次世代のセキュアなアプリケーション構築につながります。パスキーへの移行は、Web認証の未来を形作る重要な一歩となるでしょう。