パスキーはなぜ「盗まれても意味がない」のか。新社会人エンジニアが知っておきたい公開鍵の考え方

「パスキーでログインしてください」と言われ、指紋をかざすだけで入れてしまう。便利だけれど、なんだか落ち着かないと感じたことはありませんか。

この記事では、いま対応サービスが増えている「パスキー」の仕組みを、公開鍵の考え方からかみくだいて説明します。読み終わるころには、なぜパスワードより安全なのか、そしてどこに弱点があるのかを自分の言葉で言えるようになります。

結論を先に言うと、パスキーが強いのは「秘密をサーバーに置かない」からです。守り方を工夫したのではなく、守るべき秘密の置き場所そのものを変えた仕組みです。

目次

パスキーとは?パスワードと何が違う認証なのか

パスキーは、パスワードの代わりに公開鍵の技術でログインする仕組みです。合い言葉を送り合うのをやめた認証方式、と考えてください。

パスワード方式の弱さは、サービス側にも秘密が置かれる点にあります。利用者とサーバーが同じ秘密を共有しているため、サーバーが漏れれば秘密も一緒に漏れます。

パスキーではこの前提が変わります。登録するとき、手元のスマホやパソコンがその場で鍵のペアを作ります。秘密鍵は手元に残り、サーバーに送られるのは公開鍵だけです。

身近な例でたとえてみましょう。公開鍵は「鍵穴」、秘密鍵は「その鍵穴を開けられる鍵」です。鍵穴の写真をいくら配っても、そこから鍵そのものを作ることはできません。

なお、指紋や顔認証はパスキーそのものではありません。手元の端末のロックを外し、本人だと確かめるための手段です。生体の情報がサービス側に送られることはありません。

パスキーが「盗まれても意味がない」と言える理由

サービス側から情報が漏れても、出ていくのは公開鍵だけです。だから、それだけではログインを装えません。

理由は単純で、秘密鍵が一度もサーバーを通っていないからです。攻撃する側から見ると、奪いたいものが最初からそこに置かれていません。

ログインのときのやり取りも見ておきましょう。サーバーは毎回違う短いデータを送ります。これを「チャレンジ」と呼びます。手元の端末は秘密鍵でそれに署名を付けて返し、サーバーは預かっている公開鍵で確かめます。

ここで大事なのは、通信を流れるものが毎回変わる点です。同じ文字列が何度も飛ぶパスワードと違い、一度きりの署名を横取りしても、次のログインには使えません。

つまりパスキーは、盗む価値のあるものを置かず、盗んだものを使い回せなくした設計になっています。

パスキーがフィッシングに強いのはドメインを照合するから

偽サイトに誘い込まれても、パスキーではそもそも署名の処理が始まりません。

パスキーは、登録したサイトのドメインと結びついているためです。ログインしようとすると、ブラウザとOSが登録時のドメインと今いるドメインを照らし合わせます。一致しなければ、そこで止まります。

たとえば、本物そっくりのログイン画面がメールから届いたとします。人の目は見た目でだまされますが、ブラウザは文字列としてドメインを見ているので、だまされません。パスワードなら、本人が入力してしまった時点で終わりです。

ここが実務でいちばん効く部分です。「あやしいリンクを踏まないよう気をつける」という注意ではなく、踏んでも成立しない仕組みで防いでいます。

パスキーの弱点は「秘密鍵をどこに置くか」にある

一方で、パスキーは万能ではありません。弱点は秘密鍵の置き場所に集まります。

置き方は大きく2種類あります。

  • 同期タイプ: iCloudやGoogleのパスワードマネージャー経由で、暗号化された状態で複数の端末に配られる
  • 端末固定タイプ: 物理的なセキュリティキーなどに入り、その機器から外に出ない

同期タイプは便利ですが、秘密鍵の実体が「パスキーを預けているアカウント」という1か所に集まります。そのアカウントを乗っ取られると、パスキーを登録したすべてのサイトに影響が出ます。サービス側が漏れても平気、という話とは別の問題です。

端末固定タイプは安全ですが、今度は使えなくなる不安が残ります。機種を変えたときに引き継げず、一部のサービスに入れなくなる例も報告されています。

要するに、安全性と使いやすさは引っ張り合いの関係にあります。だからこそ、予備のパスキーを別の端末にも登録するといった備えが必要になります。

新社会人エンジニアがパスキーから学ぶべきこと

覚えておきたいのは実装の手順ではなく、「秘密を預からない」という発想そのものです。

手順のほうは、FIDO2やWebAuthnという共通の決まりごとと、それに沿ったライブラリに乗れば調べながら書けます。差がつくのは、どこに秘密を置くかを決める場面です。

日々の仕事では、次のような形で効いてきます。

  • 自分が作る機能で、そもそもサーバーに秘密を保存しない選び方がないか考える
  • 認証を作るときは、端末をなくした人がどう戻ってこられるかを最初に決める
  • 利用者に「注意してください」と求める対策は、仕組みで防げないか疑ってみる

どれも派手さはありませんが、設計の良し悪しが出るのはこうした判断です。仕様どおり動かすだけでなく、前提を疑える人はチームの中で頼られます。

まとめ:パスキーから持ち帰る3つのポイント

  • パスキーは公開鍵を使う認証で、秘密鍵は手元から出ず、サービス側には公開鍵だけが渡る
  • 毎回違うチャレンジへの署名とドメインの照合により、情報の漏えいとフィッシングの両方に強い
  • 弱点は秘密鍵の置き場所で、同期の便利さは集約のリスクや端末紛失時の不便さと引き換えになる

まずは普段使っているサービスの設定画面を開き、パスキーを登録できるか確かめるところから始めてみてください。

参考リンク

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

コメント

コメントする

目次