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

2026年8月14日2026年10月18日

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

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

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

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

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

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

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

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

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

図: パスキーの仕組み:サーバーが持つのは鍵穴だけなので盗んでも開かない（筆者作成）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

パスキー導入の検討で必ず揉める3つの論点(管理側の視点)

仕組みの美しさは本文のとおりですが、筆者が社内システムの認証方式の検討に関わった経験から言うと、パスキー導入の議論は暗号の話ではなく、運用の泥くさい論点で止まります。導入検討で必ず出る3つを紹介します。これを知っておくと、認証の話題で一歩深い議論ができます。

機種変更・紛失のリカバリー: 秘密鍵は端末にあるので、端末を失えばログイン手段も失う。同期型パスキーやバックアップ手段をどう案内するか、ヘルプデスクの復旧フローをどう組むかが実は本丸。リカバリー手段が電話サポート頼みだと、そこが新たな攻撃面(なりすまし電話)になる
共有端末の扱い: 工場や店舗の共用PCのように「1人1端末」が前提にできない現場では、パスキーの設計は途端に難しくなる。全社一律ではなく利用シーン別の設計になる
移行期間の二重運用: 全員が一斉に切り替わることはないので、パスワード併用期間が必ず生じる。この期間はフィッシング耐性がパスワード側の弱さに引きずられる。「管理者アカウントから先に必須化する」のが定石

新人の方は、「パスキーは安全」で止まらず、「安全な仕組みを、人の運用にどう乗せるか」まで考えられると、認証に限らずどの分野でも設計の議論に加われるようになります。セキュリティの実務は、いつも技術と運用の間にあります。

パスキーがなぜ偽サイトに強いのかを、SMS認証や認証アプリと並べて比べたい人はSMS認証が弱いと言われる3つの理由も読んでみてください。

パスキーのようなフィッシングに強い認証は、ゼロトラストで削れない土台の1つです。運用でどう効かせるかはゼロトラストに完成はない｜侵入ゼロより検知と復旧を測る理由で整理しています。