【要約】Authenticatorアプリの仕組み — MFAの中のTOTPを自作する [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
パスワード単体ではフィッシングや流出に脆弱である。主な課題は以下の通り。
- ・SMS OTPにおけるSIMスワップ攻撃のリスク。
- ・TOTPにおけるフィッシング耐性の低さ(人間がコードを入力するため)。
- ・共有秘密(K)の漏洩による、全ユーザーのコード生成リスク。
- ・デバイス紛失時のリカバリコストの高さ。
// Approach
RFC 6238に準拠したアルゴリズムを以下のステップで実装する。
1.共有秘密(K)をBase32デコード。
2.現在時刻を30秒単位のカウンタ(T)に変換。
3.
hmac.new(key, msg, hashlib.sha1) を用いてダイジェストを生成。4.ダイジェストの末尾からオフセットを特定し、4バイトを抽出。
5.抽出した値を整数化し、
code % (10 ** digits) で指定桁数に圧縮。// Result
Pythonによる簡潔な実装で、Google Authenticatorと同一のコード生成が可能であることを確認。実装の容易さとオフライン動作の利点を実証した。今後は、フィッシング耐性の高いPasskey(WebAuthn)への移行が推奨される。
Senior Engineer Insight
> TOTPはデプロイコストが極めて低く、現実的なMFA導入手段だ。しかし、鍵管理が単一故障点(SPOF)となる。アプリの同期機能やクラウド保管の暗号化強度を精査せねばならない。また、フィッシング耐性の欠如は、高価値なアカウントにおいては致命的だ。設計思想として、TOTPを「導入の容易な第一歩」と位置づけ、将来的なPasskeyへの移行パスを確保しておくべきである。