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
LLM 101
dalinaum
0
460
AWS CDKを理解するために公式の定義を深掘って解説してみる / Understanding AWS CDK by Digging into Its Official Definition
akihisaikeda
2
210
Vue.jsで作る空間解析アプリとCapacitorプラグインのData Bridge
hal_spidernight
1
160
PumaからFalconに移行したRailsアプリケーションでの実践
falcon8823
0
340
Railsバージョンを4倍にした話
optim
0
920
社内AIエージェント「Askワンバン」における コストチューニングの取り組み
t0yohei
0
150
Crash Auto Pipelines
veronikapj
1
350
조합이폭발하는디자인시스템이걸눈으로도테스트하라고요
giljongyu
0
710
Coding with AI: How to trust the storyteller (AWS Community Day Adria, Ljubljana 2026)
slobodan
0
140
Vapor Mode でアクセシビリティは 壊れないか検証した話
fuqda
1
320
Kotlinの15年とServer-Side Kotlin
n_takehata
1
190
高橋メソッドでCVE解説シリーズ 〜CVE-2026-112816〜
hakkadaikon
0
200
Featured
See All Featured
Thoughts on Productivity
jonyablonski
76
5.4k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.7k
Paper Plane
katiecoart
PRO
5
54k
Ten Tips & Tricks for a 🌱 transition
stuffmc
1
280
Navigating the moral maze — ethical principles for Al-driven product design
skipperchong
2
680
Raft: Consensus for Rubyists
vanstee
143
7.8k
Primal Persuasion: How to Engage the Brain for Learning That Lasts
tmiket
0
510
First, design no harm
axbom
PRO
2
1.4k
Typedesign – Prime Four
hannesfritz
42
3.2k
A designer walks into a library…
pauljervisheath
211
25k
Are puppies a ranking factor?
jonoalderson
2
4.1k
16th Malabo Montpellier Forum Presentation
akademiya2063
PRO
0
450
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