【要約】パスキーはなぜ「盗まれても意味がない」と言えるのか - 真価を発揮する使い方 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
従来のパスワード認証では、ユーザーが偽サイトに秘密情報を入力してしまうリスクが常にある。攻撃者は人間が偽サイトを見抜けない隙を突き、認証情報を直接奪取できる。具体的には以下の問題が存在する。
- ・パスワードは「同じ秘密」をサービスに渡すため、漏洩が即座に不正ログインに繋がる。
- ・サービス側のデータベースが攻撃を受けると、認証情報が大量に流出するリスクがある。
- ・フィッシングサイトによる偽装に対し、人間による判断だけでは防御が困難である。
// Approach
パスキーは、公開鍵暗号とWebAuthnを用いることで、秘密情報を渡さずに本人確認を行う。認証時に秘密鍵そのものを送信せず、チャレンジに対する署名のみをやり取りする。具体的な手法は以下の通りである。
- ・登録時に、サービス側には公開鍵、端末側には秘密鍵を生成・保持させる。
- ・認証時は、サービスが発行したChallengeに対し、秘密鍵で署名を行い検証する。
- ・WebAuthnがOrigin（接続先ドメイン）を検証し、偽サイトでの署名を防ぐ。
- ・物理キー（Titan Security Key等）を利用し、デバイス固定型の高い強度を実現する。
// Result
パスキーの導入により、サーバー側のデータ漏洩やフィッシング攻撃に対する耐性が劇的に向上する。公開鍵が漏洩しても、秘密鍵がなければ不正な署名は作成できない。ただし、以下の点に留意が必要である。
- ・パスキー自体は、端末のロック解除（生体認証等）を保証するものではない。
- ・アカウント復旧フローが弱いと、そこが攻撃の突破口となる。
- ・ログイン後のセッションCookieが盗まれる「セッションハイジャック」には無力である。
- ・真の安全には、認証方式だけでなく、アカウント全体の設計見直しが不可欠である。
Senior Engineer Insight
> パスキー導入は、認証の「点」ではなく「線」で設計すべきである。認証方式を強化しても、復旧フローやセッション管理が脆弱であれば、攻撃者は容易に迂回する。実戦投入においては、WebAuthnの導入に加え、重要操作時の再認証、DBSCによるセッション保護、および強固な復旧手段の設計をセットで検討せよ。利便性と強度のトレードオフを考慮し、同期型とデバイス固定型を使い分ける設計が、運用コストとセキュリティのバランスを取る鍵となる。