パスキーはパスワードと何がちがうの？（414号）

パスキーについては、2年前の2023年6月に書きました。

　No310　パスキーはパスワードを置き換えるのか？（2023年6月配信）
　https://note.com/egao_it/n/ndbaff037d2da

今回は、そのアップデート版をお送りします。

パスキーについては技術的にはかなり複雑な仕組みとなっていますので、今回はパスキーのメリットなどをお話します。
次回（以降も？）はパスキーの技術面のお話をする予定です。


1. パスワードの課題

これを書いている2025年現在、「パスワードなんて聞いたこともない」という方はかなりレアでしょう。

それほど一般化した用語であるにも関わらず、パスワードには多くの課題があります。

　・パスワードの使い回し
　・簡単なパスワード
　・サイバー攻撃によるパスワードの漏洩

事業者側は、パスワードの使い回しや、簡単なパスワード（123456など）を使わないように注意喚起しますが、「複雑なものは覚えられない」「サービス毎に使い分けるなんてムリ」といった利用者側の都合もあります。

結果として、パスワード方式が安全に運用できているとはいい難い状況が続いています。

一方で、事業者側へのサイバー攻撃、フィッシング詐欺によるパスワード窃取も発生しており、パスワードによる利用者保護はますます難しくなってきています。

パスワードというのは、事業者側も利用者側も守らなねばならない負債を増やすばかりです。

もし、パスワードのような記憶に頼らないで済む方式があれば、サービス事業者側もサービス利用者側も幸せなのは間違いありません。


2. バイオメトリックス認証

記憶に頼らないとなると、誰もが思い付くのは、バイオメトリクス（生体）認証です。

指紋、顏認証などはスマホでもお使いの人が多いでしょう。
厳重に入室制限したい設備などでは、静脈認証（指の中の静脈パターンを読み取る）や虹彩認証（目の中の瞳部分のパターンを読み取る）といった認証方法も実用化されています。

このバイオメトリクス認証、パスワードを補強する手段としては最強といっていいのですが、パスワードの代用品にはなれない欠点があります。

最も問題となるのは、生体情報には「変化」がありうる点です。
例えば、指紋であれば、お風呂から出た直後は指がふやけてしまっていますから、指紋認証が使えません。また、指を切ってしまって、指紋パターンが変わる、目の病気などで虹彩パターンが変わるといった事故があると、パターンの再登録が必要です。

では、パターンの再登録時の本人確認はどうするのか？
結局、再登録のためにパスワードやPINコード（スマホなどで6ケタ程度の数字を選択するアレ）が必要となります。

仮にバイオメトリクス認証以外の手段がないとすると、事故が起きた時に永遠にその機器が使えなくなってしまいます。

だからといって、バイオメトリクス認証の価値がないというわけではありません。
スマホなどで簡便にロック解除できる（人に見られても心配ない）など利便性の高い認証方式ですから、使っていただいても全く問題ありません。


3. パスキー

さて、パスワードには「漏洩するかもしれない」という課題があり、バイオメトリクス認証には「変化に弱い」という課題があります。

この両者の課題を完全に技術論だけで解決しようとして開発されたのが、パスキーという方式です。

パスキーはいわばブランド名で、技術的にはFIDO（ファイド）アライアンスという団体が提唱するFIDO2認証方式です。

このFIDO2の最大の特徴は、パスキーそのものはスマホやパソコン内部だけに存在し、利用者ですら見ることができないという徹底的な秘密主義が貫かれている点にあります。（絶対に見られないか？というと機種にもよるんですが...まあ普通は見られません）

利用者ですら見られないのですから、パスワードのようにフィッシングメールなどで騙されて入力してしまう、という事故は100%防げます。

また、サービス事業者側、言い換えればパスキーが正しいかどうかをチェックする側、にはパスキーは存在しません。
パスキーなしで、どうやって本人確認するのかというと「正しいパスキーならこうなるはずの値（以下、検証用の値と書きます）」だけが存在します。

筆者がよく例えに使うのは「老舗うなぎ屋のタレのレシピ」です。

登場人物は３人。
　お店のオーナ：利用者
　大将：（スマホ、パソコン内の）セキュリティモジュール
　お客：サービス事業者

補足：
　一般にお店＝サービス事業者、お客＝利用者ですが、ここでは逆転しています。
　「お店」はスマホやパソコンを指し、サービス事業者ではありません。
　混乱のないようにご注意ください。

タレのレシピは店の大将（セキュリティモジュール）しか知りません。
お客（サービス事業者）が知らないのはもちろんですが、お店のオーナ（利用者）にも教えてくれません。

お客が来る（サービスの利用を始める）と、大将（セキュリティモジュール）にうな丼（認証コード）を作ってよ、と依頼します。
大将はうな丼を作り、お客に提供します。

お客は「うん、確かに大将の作ったウナギだ。ウマー」（検証用の値と比較して正しいことを確認）すると、ログインを許可します。
これが、「ん？なんかいつもと味が違うぞ」（検証用の値と合わない）となるとログインが拒否されます。

ここで、重要なのは、レシピは大将の頭の中にしかなく、門外不出だという点です。
仮にサービス側がサイバーアタックを受け、秘密情報が根こそぎ盗まれたとしても、そこにはレシピはなく、「検証用の値」しかありません。

また、お店のオーナもレシピは知りませんから、仮に悪意の第三者がレシピを盗み取ろうとしても、知らないものは洩れようがありません。

しかも大将はガンコなので、ユーザ側の正式な依頼（バイオメトリクス認証やPINコード入力）がないとテコでも動こうとしません。

つまり、パスキーでは「うっかり洩らす」可能性はゼロで、サービス事業者側から洩れる心配もないのです。

これがパスキー方式がパスワードを置き換える最有力候補と言われる理由です。


4. パスキーとバイオメトリクス認証は違う

実は今回の記事で一番書きたかったのがこの点です。

多くのスマホやパソコンではパスキーの使用時に本人認証を求められます。その多くはバイオメトリク認証を使います。

なので、パスキー＝バイオメトリクス認証、と誤解している方が意外に多いのですね。

ですが、「うなぎ屋のレシピ」の例を思い出してください。
パスキーであるレシピは大将（セキュリティモジュール）しか知りません。

お客（事業者側）「大将、うな丼を作ってよ」と依頼された時でも、お店のオーナ（利用者）が「うん」と言わない（バイオメトリクス認証やPINコード入力で本人確認をしない）限り、テコでもうな丼を作ってくれません。

つまり、パスキーの利用を求める際に指紋や顔認証するのは、大将にうな丼を作ってもらうためであり、それ自体で認証をしているわけではないのです。


5. デメリットも...

情報セキュリティ対策に100点はありません。
完全に見えるFIDO2認証ですが、デメリットもあります。

最大の問題はスマホやパソコンなどに入っているパスキーを失った時のことです。
特に機器の盗難や故障でパスキーが使えなくなった場合は大変です。

パスワードであれば、本人が覚えていさえすれば本人確認は可能です。
ですが、パスキーが入っている認証端末が使えなくなると本人確認できなくなります。

その場合はパスキーを再発行することになります。
再発行といっても、キー自体はスマホやパソコン内にしかありません。大将の頭の中にしかレシピがないのと同じです。
なので、復元はできませんが、新しいパスキーを再作成して、そちらを新しいパスキーとして登録しなおすことはできます。

また、2025年現在、FIDO2が使えるサービスがまだ限定的なことも課題です。
既にスマホやパソコン側は2022年頃にはパスキーを利用できる状態となっています。（お店も大将も存在している状態）
ですが、サービス事業者側の対応はまだまだです。現状は「パスキー認証」未対応の事業者が大半なのです。

とはいえ、大手を中心に対応は進んでいますので、今後は使えるシーンが増えると思われます。


6. まとめ

パスワードの多くの課題を解消する仕組みとして、パスキーという方式がゆっくりですが、浸透しつつあります。

何よりも大きなポイントは、パスキーなら、認証情報の漏洩可能性が理論的にゼロである点です。
サービス事業側には、パスキーは存在せず（検証用の値のみ存在）、利用者本人もパスキーを知ることはできません。

パスキーはスマホやパソコンの最深部に大事にしまわれていて、その利用はセキュティモジュール（うなぎ屋の大将）にしか許されていません。

つまり、サービス事業者側からも、端末側からも、利用者側からも洩れない設計になっているのですね。

次回（次々回まで続くかも）は「パスキーって技術的にどんな仕組みなの？？ということをお話します。

今回はパスキーについて解説しました。
次回もお楽しみに。

今日からできること：
　・パスキーは超安全な認証方式
　　→使えるサービスでは是非利用を！
　・パスワードの使い回しをやめよう！
　　→使い回しを止めるにもパスキーは有効
　　→パスキーが使えくてもブラウザのパスワード管理機能で回避
　　　詳しくは以下で
　　　　パスワードの作り方2024（375号）
　　　　https://note.com/egao_it/n/n6f5be9b7502e 

（本稿は 2025年7月に作成しました）