Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
パスキーはなぜフィッシングに強いのか
Search
赤神青空
PRO
November 03, 2026
Video
Programming
26
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
パスキーはなぜフィッシングに強いのか
赤神青空
PRO
November 03, 2026
Video
More Decks by 赤神青空
See All by 赤神青空
【AIニュース】OpenAI も Claude も Google Cloud で使える?
akagami
PRO
0
3
【基本情報対策】TCP/IPとOSI参照モデル
akagami
PRO
0
8
AWS Continuum とは何か
akagami
PRO
0
6
【力学 #3】斜方投射を成分に分けて解く
akagami
PRO
0
9
Anthropic の OSS Scanner、AI が脆弱性を探して修正まで出す?
akagami
PRO
0
15
Claude API の temperature が消えた?
akagami
PRO
0
17
GPT-6.1 Terra とは何か
akagami
PRO
1
43
【力学 #2】空気抵抗のある落下と終端速度
akagami
PRO
0
17
【基本情報対策】SQLとトランザクション
akagami
PRO
0
30
Other Decks in Programming
See All in Programming
Enforcing Your Architecture with Unit Tests in the AI Era (Swift Connection X)
steliosf
PRO
1
120
Snowflake Openflow Connector利用の勘所 / 20261024developersio2026tokyo-snowflake-openflow
kasacchiful
PRO
0
280
コーディング自動化の次へ。人の介入をゼロにするファクトリーとサポートAIによる実践
timakin
5
5.1k
クラウドゲーミングのパフォーマンス最適化に挑む / Cloud Gaming Performance Tuning
vivion
0
320
3回つくってわかった、 定期実行ジョブ基盤の本質情報
takai
4
3.7k
AIが実装を担う時代の「技術設計」と「チームマネジメント」
kamina_zzz
1
130
複数ドメインを一つのアプリに統合するFlutterの設計と運用_FlutterKaigi2026登壇資料(須永高弘)
takahirosunaga
0
140
flutter_test のその先へ — Flutter アプリの LLM 機能に「評価」という品質保証を
kosukesaigusa
0
180
[DroidKnights 2026] Workflow AX: From Auto-Documented Policies to E2E Testing
raeminkang
0
510
Coding with AI: How to trust the storyteller (AWS Community Day Adria, Ljubljana 2026)
slobodan
0
140
AI時代のIaC入門 〜なぜインフラをコードで管理したいのか?〜 / Introduction to IaC in the AI Era
akihisaikeda
6
1.4k
作れるエンジニアから、価値を届けるエンジニアへ
ryunakayama
1
120
Featured
See All Featured
Design in an AI World
tapps
1
380
Agile that works and the tools we love
rasmusluckow
331
22k
The Mindset for Success: Future Career Progression
greggifford
PRO
0
560
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
659
62k
Digital Projects Gone Horribly Wrong (And the UX Pros Who Still Save the Day) - Dean Schuster
uxyall
1
3.7k
My Coaching Mixtape
mlcsv
0
380
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
3.1k
JAMstack: Web Apps at Ludicrous Speed - All Things Open 2022
reverentgeek
1
670
Code Reviewing Like a Champion
maltzj
529
40k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
10
1.4k
Mobile First: as difficult as doing things right
swwweet
225
10k
Evolving SEO for Evolving Search Engines
ryanjones
0
350
Transcript
2026年11月 パスキーはなぜ フィッシングに強いのか 鍵がサイトに紐づく仕組みと、使うときの注意 赤神 青空
▪今回の問い:パスキーでは、なぜ中継されないのか 前回のおさらい:6桁は中継される 利⽤者 6桁を⼊⼒ 偽サイト ⾒た⽬は本物そっくり その場で中継 本物のサイト 攻撃者がログインできる パスキーだと、この中継が成り⽴たない
TOTP でもメールOTP でも、⼈が打ち込む6桁は中継される(前回) 今回の問い:パスキーでは、なぜ同じことが起きないのか 今ココ 概要 2/14
▪秘密鍵と公開鍵の組で、打ち込まずにログインする パスキーとは 鍵のペアでログインする 秘密鍵と公開鍵の組を、サイトごとに作る パスワードや6桁のように、⼈が打ち込む⽂字列はない 秘密鍵は⼿元に、サーバーには公開鍵 秘密鍵は端末やパスワードマネージャーが持ち、サイトには渡さない サーバーに置くのは公開鍵。漏れても、それでログインはできない 使うときは、指紋‧顔‧PIN で確かめる
スマホのロックを解くのと同じ操作で、鍵を使ってよいと⽰す 指紋や顔のデータは、端末の中で使われ、サーバーには送られない 今ココ 概要 3/14
▪端末が鍵の組を作り、公開鍵だけをサーバーに渡す 登録のとき 端末(スマホ‧PC など) 秘密鍵 公開鍵 example.com ⽤の鍵として保存 今ココ しくみ
サーバー(example.com) 登録を始める パスキーを作ってください 公開鍵だけ送る 公開鍵を保存 このアカウントの公開鍵として 4/14
▪毎回違うチャレンジに、秘密鍵で署名する ログインのとき 端末(スマホ‧PC など) サーバー(example.com) チャレンジ 毎回違う乱数を作る 署名 公開鍵で署名を確かめる 指紋‧顔‧PIN
で確かめる 秘密鍵で署名する 合っていれば、ログインできる 今ココ しくみ 5/14
▪偽サイトでは、使える鍵が出てこない 理由①:鍵がサイトに紐づく 本物のサイトを開いたとき example.com この鍵がある 署名して、ログイン この鍵はない 使える鍵が出てこない 偽サイトを開いたとき examp
e.com ⾒た⽬が似ていても、ドメインが違えば別のサイト 鍵は作ったサイトのドメインと結び付いていて、ブラウザがそれを確かめる ⼈がアドレスを⾒分けられなくても、偽サイトには鍵が出てこない 今ココ 理由 6/14
▪中継しても、本物のサイトが気づく 理由②:署名にサイトが入る ブラウザ (偽サイトを開いている) 署名 偽サイト その場で中継 本物のサイト 署名する中⾝(⼀部をブラウザが作る) チャレンジ(毎回違う乱数)
開いているサイト:examp e.com 本物のサイトは受け付けない 署名の中のサイトが、⾃分と違う チャレンジも、その1回にしか使えない 中継しても、ログインにならない 書き込むのはブラウザ。偽サイトが書き換えることはできない 今ココ 理由 7/14
▪盗んで使い回せるものが残らない 理由③:運べるものがない 6桁(TOTP‧メールOTP) パスキー ⼈が読んで、打ち込む ⼈が打ち込むものがない 偽サイトにも打ち込めてしまう 秘密鍵は、サイトには渡らない 受け取った側が、そのまま使える 署名は、その1回のチャレンジ⽤
途中で盗んでも、次のログインには使えない 今ココ 理由 8/14
▪打ち込むもの・中継・サーバーにある秘密 6桁と比べると TOTP メールOTP パスキー ⼈が打ち込むもの ある(6桁) ある(6桁) ない 偽サイトでの中継
通ってしまう 通ってしまう 通らない サーバーにある秘密 シード 送ったコード 公開鍵だけ 今ココ 理由 9/14
▪便利になった分、同期のアカウントを守る 注意①:同期するパスキー 同期の アカウント スマホ PC‧新しい端末 例:iCloud キーチェーン、Google パスワードマネージャー 機種変更しても、作り直さずに使える
同期のアカウントが、新しい守りどころ そのアカウントを乗っ取られると、パスキーも使われるおそれがある 同期のアカウントにも、強い多要素認証を(NIST もそう求めている) 今ココ 注意 10/14
▪弱い入口が開いていれば、そこを狙われる 注意②:ほかの入口が残っていると ログイン画⾯ パスキーでログイン 弱い⼊⼝が狙われる パスワード+6桁でログイン 攻撃者は、パスキーではなく 弱いほうの⼊⼝へ誘導する メールで再設定する パスキーだけにできる所はそうする
なくしたときの戻し⽅も強くする 強い⼊⼝と弱い⼊⼝が、両⽅開いている 今ココ 注意 11/14
▪パスキーは鍵がサイトに紐づくので、偽サイトに渡しようがない まとめ 秘密鍵は⼿元に、サーバーには公開鍵 仕組み 鍵がサイトに紐づくので、偽サイトでは使えない 理由 同期のアカウントと、ほかの⼊⼝を守る 注意 ログインは、毎回違うチャレンジに秘密鍵で署名する ブラウザがサイトを⾒分け、署名にもサイトが⼊る
パスワードや6桁が残っていると、そこを狙われる 今ココ まとめ 12/14
▪一度止めて考えてみてください。答えは次のページで 今回のクイズ パスキーが偽サイトで使えない一番の理由はどれ? A 指紋や顔で本人を確か めるから 今ココ まとめ B 鍵がサイトのドメイン
に紐づくから C 秘密鍵が毎回作り直さ れるから D サーバーに公開鍵しか 置かないから 13/14
▪鍵は作ったサイトのドメインに紐づき、偽サイトには出てこない クイズの答えは「B」 今回のクイズ パスキーが偽サイトで 使えない⼀番の理由はどれ? 鍵は作ったサイトのドメインに 紐づいていて、ブラウザが それを確かめるから 答えは B
今ココ まとめ A 指紋や顔で本⼈を確かめるから 本⼈の確認。どのサイトかは⾒ていない B 鍵がサイトのドメインに紐づくから 偽サイトには、その鍵が出てこない C 秘密鍵が毎回作り直されるから 鍵は登録のときの1回。毎回違うのはチャレンジ D サーバーに公開鍵しか置かないから 漏れたときに強い理由。フィッシングとは別 14/14