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
TOTPとメールOTP、どっちが安全?
Search
赤神青空
PRO
October 24, 2026
Video
Programming
9
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
TOTPとメールOTP、どっちが安全?
赤神青空
PRO
October 24, 2026
Video
More Decks by 赤神青空
See All by 赤神青空
【基本情報対策】OSのプロセスと仮想記憶
akagami
PRO
0
9
【AIニュース】Muse Spark Open とは何か
akagami
PRO
0
14
【AIニュース】Jev とは何か
akagami
PRO
0
28
【基本情報対策】CPU・メモリ・キャッシュ
akagami
PRO
0
22
【AIニュース】Anthropic が Git から Scion に移った理由
akagami
PRO
0
31
【AIニュース】Grok Voice 3.0 とは何か
akagami
PRO
0
23
【基本情報対策】探索・整列と計算量
akagami
PRO
0
16
【AIニュース】GPT-6 の Intelligent UI とは何か
akagami
PRO
0
27
【基本情報対策】スタック・キュー・木
akagami
PRO
0
17
Other Decks in Programming
See All in Programming
機械に任せるテスト、人が見るテスト ⽣成AIで引き直した、運⽤保守フェーズの線引き
dske104
0
200
なぜCTOを降りてFDEを選んだのか?〜なぜプロダクト企業がFDEで顧客の現場に踏み込むのか〜
gonta
1
230
Jetpack Compose Mechanisms
skydoves
3
840
エージェントを使い続けるためのメタワーク / Meta-work for keeping using the agent
rkaga
4
1.4k
Long Living Tokens, Die, Die, Die! (or: The One Ring is Banned in Modern)
sylph01
0
350
IBM Bob でAI駆動開発『QC-Playbook』
ichirokano2
0
120
Performance Optimization With LLMs
xleitix
0
180
Seven New Principles of Software Engineering
yegor256
0
180
ジョジョの世界をXRで再現する
mofurune
0
180
オーケストレーション記述言語 Katari
yukikurage
0
150
AWS CDKのカスタムリソースでContinuum(旧Security Agent)を実装した話 | Implementing Continuum (formerly Security Agent) via AWS CDK Custom Resource
akihisaikeda
2
160
sbt 2.0: takeoff
eed3si9n
0
170
Featured
See All Featured
How to Think Like a Performance Engineer
csswizardry
28
2.9k
How to Grow Your eCommerce with AI & Automation
katarinadahlin
PRO
2
330
First, design no harm
axbom
PRO
2
1.3k
Done Done
chrislema
187
17k
HDC tutorial
michielstock
2
970
Information Architects: The Missing Link in Design Systems
soysaucechin
1
1.2k
Highjacked: Video Game Concept Design
rkendrick25
PRO
1
490
Statistics for Hackers
jakevdp
799
230k
Java REST API Framework Comparison - PWX 2021
mraible
34
9.8k
Writing Fast Ruby
sferik
630
63k
What the history of the web can teach us about the future of AI
inesmontani
PRO
2
750
GraphQLとの向き合い方2022年版
quramy
50
15k
Transcript
2026年10月 TOTPとメールOTP、 どっちが安全? ログインの6桁の仕組みと弱点 赤神 青空
▪今回の問い:どちらが攻撃に強いのか ログインの6桁、2つの方式 認証アプリで⾒る6桁 TOTP サービス名 30秒ごとに変わる 今ココ 概要 メールで届く6桁 メールOTP
件名:ログイン⽤の確認コード このコードを画⾯に⼊⼒してください 2/14
▪使い捨てのコードを、2要素認証の2つ目に使う ワンタイムパスワードとは 使い捨てのコード ⼀度使ったら、または時間がたったら使えなくなる ⾒られても、使える時間が短い 2要素認証の2つ⽬に使う 知っているもの(パスワード)に、別の要素を⾜す パスワードだけが漏れても、ログインされないようにする 今回⽐べるのは2つ アプリの中で計算する(TOTP)と、メールで届く(メールOTP)
この作り⽅の違いが、強さの違いになる 今ココ 概要 3/14
▪シードと時刻から、端末の中で6桁を計算する TOTP の仕組み 認証アプリ 認証アプリ(⼿元の端末) シード サーバー 登録のとき1回だけ、QRコードでシードを渡す サーバー 時刻(30秒の区切り)
決まった計算(HMAC)で6桁にする シード(保管) 時刻(30秒の区切り) 同じ計算で6桁を出す ⼊⼒された6桁と照合 今ココ しくみ 4/14
▪サーバーが作った6桁を、メールで届ける メールOTP の仕組み サーバー 乱数で6桁を作る メールサーバー を経由して 利⽤者の メールボックス 利⽤者が
画⾯に⼊⼒ コードを保存しておく ⼊⼒された6桁と照合 コードが、ネットワークを通って届く TOTP と違い、6桁そのものが送られてくる 届いたコードは、メールボックスに残る 今ココ しくみ 5/14
▪メールOTP違い①:何に守られているか の強さは、メールアカウントの強さ メールOTP TOTP メールのパスワードが漏れる メールが乗っ取られても メールアカウントが乗っ取られる シードは⼿元の端末の中 コードも、パスワードのリセットも届く 6桁は作れない
⽶国の NIST のガイドラインも、ログイン⽤のコードをメールで届ける⽅式を禁じている 今ココ 違い 6/14
▪6桁が送られてくるか、手元で作るか 違い②:コードの通り道 メールOTP サーバー メールサーバー メールボックス 画⾯に⼊⼒ 配送の途中、転送の設定、ロック画⾯の通知から⾒られることがある TOTP 端末の中で計算
画⾯に⼊⼒ サーバーから送られてくる経路がない。コードは⼿元で作られる 今ココ 違い 7/14
▪長いほど、盗まれたコードが使われやすい 違い③:使える時間 TOTP 30秒ごとに切り替わる(前後を少し受け付けることも) メールOTP サービスが決める(例:10分) 0分 2分 4分 6分
8分 10分 使える時間が⻑いほど、盗んだコードを使える時間も⻑い 今ココ 違い 8/14
▪シード・QRコード・なくしたときの戻し方 TOTP にも弱点はある サーバーがシードを保管する 保管しているシードが漏れると、全員分の6桁が作れてしまう TOTP の仕様(RFC )も、安全な場所に置くよう求めている 登録のときのQRコード QRコードには、シードが⼊っている
画⾯共有やスクリーンショットで漏れることがある 端末をなくしたときの戻し⽅ 「メールで解除」にすると、メールの強さまで下がる アプリのクラウド同期も、そのアカウントの守りしだい 今ココ 弱点 9/14
▪偽サイトに入力した6桁は、その場で中継される 共通の弱点:フィッシング 利⽤者 6桁を⼊⼒ 偽サイト その場で中継 ⾒た⽬は本物そっくり 本物のサイト 攻撃者がログインできる TOTP
でもメールOTP でも同じ 6桁は、⼈が読んで打ち込むので、相⼿が偽サイトでも渡ってしまう NIST も、OTP や別の経路で届くコードを、フィッシングに強いとはみなさない 今ココ 弱点 10/14
▪人が打ち込むものをなくす 防ぐならパスキー 6桁(TOTP‧メールOTP) パスキー(WebAuthn) ⼈が読んで、打ち込む 端末などが持つ秘密鍵で署名する どのサイトにも打ち込めてしまう 鍵はサイトのドメインに紐づく 相⼿が本物かは⾒分けない 偽サイトのドメインでは使えない
⼈が打ち込むものがないので、渡しようがない 今ココ 弱点 11/14
▪ まとめ ⽐べると、TOTP のほうが強い ⽐べると TOTP にも守るところがある 注意 フィッシングまで防ぐならパスキー その先
メールの乗っ取りに巻き込まれにくく、コードが送られてこない シードの保管、登録のQRコード、端末をなくしたときの戻し⽅ 6桁はどちらも、偽サイトでその場で中継される 今ココ まとめ 12/14
▪一度止めて考えてみてください。答えは次のページで 今回のクイズ メールOTP にはあって、TOTP にはない弱点はどれ? A 偽サイトでその場で中 継される 今ココ まとめ
B メールが乗っ取られる とコードも読まれる C 登録のときのQRコー ドから漏れる D サーバーの秘密が漏れ ると全員分作れる 13/14
▪ クイズの答えは「B」 今回のクイズ メールOTP にはあって、 TOTP にはない弱点はどれ? TOTP はコードを⼿元の端末で 作るので、メールが乗っ取られても
6桁は作れない(戻し⽅を メールにしていなければ) 答えは B 今ココ まとめ A 偽サイトでその場で中継される TOTP も同じ。どちらもフィッシングに弱い B メールが乗っ取られるとコードも読まれる メールOTP だけの弱点 C 登録のときのQRコードから漏れる これは TOTP の側の弱点 D サーバーの秘密が漏れると全員分作れる シードを保管するのは TOTP の側 14/14