BrainOTP와 TOTP (One-Time Password & Time-Based OTP)
핵심 인사이트 (3줄 요약)
- 본질: OTP(One-Time Password)는 한 번만 사용할 수 있는 비밀번호로, 매 인증 시도마다 새로운 비밀번호가 생성되어 재사용 공격(Replay Attack)을 방지하며, TOTP(Time-Based OTP)는 시계 기반 알고리즘으로 30초마다 OTP가 자동으로 갱신되어 보안성과 편의성을 모두 제공한다.
- 가치: Google, Microsoft, GitHub 등 주요 서비스가 TOTP 기반 2FA를 지원하며, SMS OTP의脆弱性이 알려지면서 TOTP/Authenticator App 방식이 권장되고 있다. TOTP는 비밀번호 유출 후에도 계정을 보호하는 2차 방어선으로, 피싱 网站에서도 TOTP 코드는 탈취하기 어렵다.
- 융합: TOTP는 HMAC-SHA1, Base32 인코딩, 시간 동기화, 그리고 이동 통신(SIM 스왑 방어)와 결합하며, FIDO2/WebAuthn의 대안 또는補完으로 활용된다.
Ⅰ. 개요 및 필요성 (Context & Necessity)
개념 정의
OTP(One-Time Password)는 문자 그대로 한 번만 사용 가능한 비밀번호로,一回限りの비밀번호라는 이름 그대로 한 번의 인증에 사용되면 즉시無効化되어 재사용이 불가능하다. 이 특성으로 인해 피싱 网站에서탈취한 OTP를再利用하는 Replay Attack을 효과적으로 방지할 수 있다. TOTP(Time-Based OTP)는 OTP의 일종으로, HMAC-Based OTP(HOTP)의基础上 시간 요소를 추가하여, 30초마다 새로운 OTP가 자동으로 생성되는 방식이다. RFC 6238에標準化되어 있으며, Google Authenticator, Microsoft Authenticator, Authy 등의 앱과 연동된다.
필요성
비밀번호만으로는 인증의 안전성을 담보할 수 없다. 비밀번호가 유출되면(피싱, 데이터 유출, 키로거) 공격자는 비밀번호만으로 계정에 접근할 수 있다. 따라서 비밀번호라는 "무언가를 아는 것(knowledge factor)"에，加えて"무언가를 가지고 있는 것(possession factor)"을 결합하는 것이 필수이며, 이것이 다요소 인증(MFA)의 기본 원칙이다. OTP는 이 "소유" 요소를 구현하는 한 방법으로, 스마트폰의 Authenticator App이나 하드웨어 토큰에서 생성된 OTP를 입력하여,万一 비밀번호가 유출되더라도 OTP 없이는 계정 접근이 불가능하도록 한다.
💡 비유
OTP는 일회용 입장 ticket과 같다. 일반 입장券(비밀번호)은何度も使用可能하지만, 도난되면 다른 사람도使用可能하다. 반면 일회용 입장券(OTP)은 使用하면すぐに無効化되어, 도난값이있더라도再利用이 불가능하다. TOTP는 30초마다 자동으로 새로운 일회용券が生成されるもので, 券を盗み取られても次の瞬間には新しい券が必要なので、犯行 группがоторможены. 이러한一次性 특성이 OTP의核心価値이다.
등장 배경
HOTP(HMAC-Based OTP)는 2005년 OATH(Initiative for Open Authentication)에서 도입되었으며, Event-Based로 카운터 값을 기반으로 OTP를 생성한다. 그러나 카운터 값의 동기화 문제가 있었고,2008년 TOTP가 RFC 6238으로标准化되어 시간 기반 OTP가 보편화되었다. 현재는 Google, Microsoft, GitHub, Dropbox, Amazon, Blizzard, Battle.net 등 대부분의 주요 서비스가 TOTP 기반 2FA를 지원한다. SMS OTP의 경우,2016년 SS7 공격, SIM 스왑 공격, 그리고OTP 탈취를 위한マskeepers의 등장으로 인해安全隐患이 확인되어, 이동 통신 기반 OTP에서 TOTP/Authenticator App 방식으로의 전환이 업계 표준으로 권장되고 있다.
Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)
TOTP 알고리즘 동작 원리
TOTP는 RFC 6238로標準화된 알고리즘으로, HMAC-SHA1, 시간 값, 비밀 키를 기반으로 6~8자리의 OTP를 생성한다. 서버와 클라이언트가 동일한 비밀 키와 시간 값을 사용하므로, 별도의 동기화 없이 독립적으로 동일한 OTP를 생성할 수 있다.
┌─────────────────────────────────────────────────────────────────────┐
│ TOTP 생성 알고리즘 │
├─────────────────────────────────────────────────────────────────────┤
│
│ [공통 Secret Key (비밀 키)] │
│
│ 예: Base32 인코딩된 32바이트 키 │
│ "JBSWY3DPEHPK3PXP" (Google Authenticator에서 사용) │
│
│ [TOTP 공식] │
│
│ TOTP = HOTP(K, T) │
│ K = 비밀 키 (Shared Secret) │
│ T = floor(Unix_Time / 30) │
│ │ │
│ └── 30초 단위 시간 카운터 │
│
│ HOTP(K, C) = Truncate(HMAC-SHA1(K, C)) │
│ │
│ 단계별 계산: │
│ 1) C = floor(Unix_Time / 30) │
│ 2) hmac = HMAC-SHA1(secret_key, C) │
│ 3) offset = last_4bits(hmac[19]) │
│ 4) p = hmac[offset]..hmac[offset+3] (4바이트) │
│ 5) p[0] = p[0] & 0x7f (상위 비트クリア) │
│ 6) otp = p % 1000000 (6자리) │
│
│ [예시] │
│
│ Unix Time = 1700000000 │
│ T = floor(1700000000 / 30) = 56666666 │
│ HMAC-SHA1(Secret, 56666666) = 1f93c... (20바이트) │
│ Truncate() → 6자리 OTP = 123456 │
│
│ [클라이언트 & 서버 독립 생성] │
│
│ 클라이언트: Authenticator App │
│ │ 스마트폰 내부 시계 │
│ │ T = floor(Time / 30) │
│ │ + 비밀 키 → TOTP 계산 │
│ │ → 6자리 코드 표시 │
│ │
│ 서버: 검증 시스템 │
│ │ 서버 시계 │
│ │ T = floor(Time / 30) │
│ │ + 비밀 키 → TOTP 계산 │
│ │ → 사용자가 제출한 OTP와 비교 │
│ │
│ ※ 시계 드리프트 허용: 일반적으로 ±1 단계 (±30초) 허용 │
│
└─────────────────────────────────────────────────────────────────────┘
[다이어그램 해설] TOTP의 핵심은 서버와 클라이언트가 동일한 비밀 키(K)와 시간 카운터(T)를 사용하여 독립적으로 같은 OTP를生成한다는 것이다. 비밀 키는 QR코드 또는手動入力으로 클라이언트에 전달되며, 이후 HTTPS/TLS 등의 안전한 채널을 통해 переда되지 않고 Local에서만 사용된다. HMAC-SHA1의 결과(20바이트)에서 마지막 nibble(4비트)을 offset으로 사용하여 4바이트를 추출하고, 그 중 상위 비트를 Clear한 후 modulo 1000000하여 6자리 OTP를 생성한다. 서버는 사용자가 제출한 OTP와 서버가 독립적으로 계산한 OTP를Constant-time 비교하여 검증한다. 시계 드리프트(클라이언트 시계가 서버 시계와 어긋나는 현상)를 고려하여 일반적으로 ±1 단계(30초 전후)를 허용하므로, OTP 입력 시간이 약 90초 정도 여유가 있다.
HOTP vs TOTP
HOTP와 TOTP는 모두 OATH 표준이지만, 카운터 방식에서根本적 차이가 있다.
| 비교 항목 | HOTP (Event-Based) | TOTP (Time-Based) |
|---|---|---|
| 카운터 기준 | 이벤트(버튼 클릭)마다 증가 | 시간 (30초마다 자동 증가) |
| 동기화 | 서버-클라이언트 카운터 동기화 필요 | 시간 기반이므로 자동 동기화 |
| 보안 측면 | 재사용 가능성 (동일 OTP 여러 번 입력) | 시간 제한으로 재사용 어려움 |
| 편의성 | 매번 버튼 클릭 필요 | 자동 생성, 클릭 불필요 |
| 표준 | RFC 4226 | RFC 6238 |
| 권장 | 과거 (HOTP) | 현재 (TOTP 권장) |
OTP 공격 유형 및 방어
OTP는 강력한 인증 수단이지만, 다양한 공격 벡터가 존재하며 이에 대한 방어가 필요하다.
┌─────────────────────────────────────────────────────────────────────┐
│ OTP 공격 유형 및 방어 │
├─────────────────────────────────────────────────────────────────────┤
│
│ [공격 1: Replay Attack] │
│ 설명: OTP를 탈취하여 재사용 │
│ 방어: TOTP의 시간 제한 (30초)으로 자연스럽게 방지 │
│ │
│ [공격 2: 피싱 (Phishing)] │
│ 설명: 피싱 网站가 사용자를 속여 OTP를 입력받、脱취 │
│ ⚠️ TOTP는 시간 제한으로 인해 피싱 어려움 (지연 시 OTP 만료) │
│ ⚠️ 단, 실시간 피싱 (OTP를即시 전송) 시 가능 │
│ 방어: FIDO2/WebAuthn (phishing-resistant) 도입 검토 │
│
│ [공격 3: SIM 스왑 (SMS OTP)] │
│ 설명: 통신사 사회공격으로 타인의 SIM을 부정하게 활성화 │
│ 방어: SMS OTP不使用, TOTP/Authenticator App 사용 │
│
│ [공격 4: Man-in-the-Middle (MITM)] │
│ 설명: HTTPS 프록시 등으로 OTP 가로채기 │
│ 방어: OTP 직접 입력 (클립보드 복사 허용 않을 것) │
│
│ [공격 5: Social Engineering] │
│ 설명: 사기 전화/이메일로 OTP를电话으로 말하게 함 │
│ 방어: OTP를絶対 타인에게 말하지 말라는 교육 │
│
│ [공격 6: Theft of Authenticator Device] │
│ 설명: 스마트폰/하드웨어 토큰 도난 │
│ 방어: 기기 잠금 (PIN/생체) +_backup codes / 대체 인증 방법 │
│
└─────────────────────────────────────────────────────────────────────┘
[다이어그램 해설] TOTP의 시간 제한(30초)은 가장 강력한 방어선으로, 탈취한 OTP를 나중에再利用하기 어렵게 만든다. 그러나 실시간 피싱(프록시 网站 등)에서는 공격자가 사용자로부터 OTP를 입수하는 순간клиента가 서버에 전송하는OTP를 탈취할 수 있으므로, 완벽한 방어는 아니다. SMS OTP는 SIM 스왑 공격에 취약한데, 공격자가 통신사를 속여 victim's SIM을 자신의 기기에 활성화하면 OTP를 탈취할 수 있다. 따라서 SMS OTP는권장되지 않으며, TOTP/Authenticator App 방식이다. Authenticator 기기 도난 시를 대비해, 미리 생성된 백업 코드(一次性 코드 리스트)를 안전한 곳에保管하거나, 대체 인증 방법(생체 인식, 이메일 등)을 등록해두는 것이 권장된다.
TOTP Secret 관리
TOTP의 보안은 Secret Key(비밀 키)의安全管理에 달려 있다. Secret Key가 유출되면 공격자도 동일한 OTP를生成할 수 있다.
┌─────────────────────────────────────────────────────────────────────┐
│ TOTP Secret 관리 아키텍처 │
├─────────────────────────────────────────────────────────────────────┤
│
│ [Secret Key 생성 및 배포] │
│
│ 서버: cryptographically secure random으로 20바이트 Secret 생성 │
│ │ │
│ ▼ │
│ QR코드 또는手動입력용 Base32 문자열으로 변환 │
│ │ │
│ ▼ │
│ 사용자에게 安全하게 전달 (첫 설정 시) │
│ │ │
│ ├── QR코드 (HTTPS 사용, 카메라로 스캔) │
│ └── 수동 입력용 Base32 문자열 (otpauth:// URI) │
│
│ [Secret Key 저장] │
│
│ ⚠️ 서버 저장: hashed orEncrypted形态로 저장 │
│ - 원본 Secret 저장 시 유출 위험 │
│ - AES-256으로 암호화하여 저장 권장 │
│
│ ⚠️ 클라이언트 저장: Secure Enclave/TrustZone 활용 │
│ - 스마트폰의 hardware-backed secure storage 활용 │
│ - biometrics으로解锁 필요 │
│
│ [Secret Key 복원/백업] │
│
│ - QR코드 재표시 (재설정 시 새 Secret 발급) │
│ -encrypted 백업 (비밀번호로 암호화된 형태로 내보내기) │
│ -纸质 백업 (수기 기록 - 엄격한 물리적 보안 필요) │
│
└─────────────────────────────────────────────────────────────────────┘
[다이어그램 해설] TOTP Secret Key는 서버에서 생성되어 클라이언트에 전달되는데, 이 과정이TOTP 보안의 가장脆弱한环节이다. 첫 설정 시 HTTPS 연결을 통해 전달되어야 하며, QR코드는 него一旦 사용되면 폐기하고, 혹시 스캔이 기록될 경우secret가 유출될 위험이 있다. 서버 측에서는secret를 AES-256 등으로 암호화하여 저장하거나, 복호화 키를 HSM/KMS로管理해야 하며, 가능하다면 secret를 хранить하지 않고 검증 시점에のみ복호화하여 사용하는 것이 권장된다. 클라이언트 측에서는 스마트폰의 Secure Enclave(Apple) 또는 TrustZone(ARM)에서secret를hardware-backed storage에保存하고,生物 인식 또는 PIN으로만解锁 가능하도록 하는 것이 가장 안전한 구조이다. 기기 분실/교체 시를 대비해, 미리 생성된纸质 백업 코드나 encrypted 내보내기 기능을 활용하여 secret를 복구할 수 있어야 한다.
- 📢 섹션 요약 비유: TOTP는 30초마다 자동으로 바뀌는 일회용 열쇠와 같다. 열쇠가 도난되더라도 30초가 지나면 그 열쇠는 사용할 수 없어서盗贼가次の階段に進む前に 열쇠가無効化된다. 하지만 열쇠의 元の秘密情報(secret key)가 유출되면盗贼도 같은 열쇠를 생성할 수 있으므로, secret key를 잘管理하고,万一에 대비해 백업 열쇠(복구 코드)를 안전한 곳에 보관하는 것이 필수이다.
Ⅲ. 융합 비교 및 다각도 분석
OTP 전송 방식 비교
| 방식 | SMS OTP | Voice OTP | Email OTP | TOTP (App) | Hardware Token |
|---|---|---|---|---|---|
| 편의성 | 높음 | 중간 | 중간 | 높음 | 중간 |
| 보안 | 낮음 | 낮음 | 중간 | 높음 | 매우 높음 |
| 비용 | 높음 (SMS 비용) | 높음 | 낮음 | 낮음 | 높음 (토큰 비용) |
| 주 공격 | SIM 스왑 | SIM 스왑 | 邮箱 탈취 | 기기 도난 | 기기 도난 |
| 권장 | ❌ | ❌ | ⚠️ | ✅ | ✅✅ |
과목 융합 관점
- 암호학: TOTP는 HMAC-SHA1 기반의 one-way hash 함수로設計되어,Secret Key 없이는 OTP를 생성할 수 없도록 되어 있다.
- 네트워크 보안: TOTP Secret 전송 시 HTTPS/TLS 사용이 필수이며, Man-in-the-Middle 프록시로 Secret이 탈취되지 않도록Certificate Pinning 등이 권장된다.
- 移动通讯安全: SMS OTP의脆弱性(SIM 스왑, SS7 공격)으로 인해 이동 통신 기반 OTP에서 App 기반 TOTP로의 전환이 가속화되고 있다.
Ⅳ. 실무 적용 및 기술사적 판단
실무 시나리오
-
시나리오 — GitHub 2FA 적용: GitHub에서 2FA(TOTP) 적용 시, Authenticator App에 계정을 등록하고, Recovery Code를 안전한 곳에 백업하는 과정. 조직 전체에 TOTP를 의무화하여,万一社員의 계정이 Compromised되더라도OTP가 없이는 접근이 불가능하도록加固.
-
시나리오 — 금융 서비스의 OTP 고도화: 국내 주요 은행에서ねるSMS OTP에서 TOTP/Authenticator 방식으로 전환한 사례. SMS의 SIM 스왑 취약성이 알려진 이후, 고객财产安全 보호를 위해 이동 통신 기반에서 앱 기반으로迁徙.
도입 체크리스트
- 기술적: TOTP Secret를 암호화된 형태로 저장하고 있는가? 서버-클라이언트 시간 동기화가 가능한가?
- 운영·보안적: 기기 분실 시 복구 프로세스가 있는가? 사용자에게 OTP를 절대 타인에게 말하지 않도록 교육하고 있는가?
안티패턴
-
SMS OTP 사용: SIM 스왑, SS7 공격에 취약하므로 사용을 피하고 TOTP/App 방식을 사용해야 한다.
-
Secret Key 평문 저장: 서버가 Compromised되면Secret가 유출되어OTP 보안을的意义가 없어진다.
-
OTP를 여러 계정에再利用: 각 계정마다 다른Secret Key를 사용해야 하며,Secretが使い回し되면 하나의 계정 유출로 다른 계정도 위험에 노출된다.
-
📢 섹션 요약 비유: OTP는 30초마다 새로生成되는 일회용 열쇠와 같아서,たとえその 열쇠를盗み取られても、30초後には新しい 열쇠가 필요하므로、犯行の機会が制限される. しかし、元となる열쇠의 비밀 정보(Secret Key)가 있어야 같은 열쇠를 生成할 수 있으므로, Secret Key의 안전한 保存와 함께，万一에 대비한 백업 열쇠(복구 코드) 관리가 필수다.
Ⅴ. 기대효과 및 결론
정량/정성 기대효과
| 구분 | 비밀번호만 | + SMS OTP | + TOTP | 개선 효과 |
|---|---|---|---|---|
| 정량 | 계정 탈취 위험 높음 | SIM 스왑으로突破 가능 | Secret Key 없이는突破 어려움 | 탈취 위험大幅 감소 |
| 정성 | 피싱에 완전 취약 | 피싱에 취약, SMS 보안 문제 | 피싱 어렵, 시간 제한으로 재사용 불가 | 계정 보안도大幅 향상 |
미래 전망
TOTP의 강화된 버전으로,推送通知 기반 인증(Push Notification-based Authentication)이 널리 사용되고 있다. 이 방식은 사용자가 로그인 시도를 확인하고,_push 버튼 하나만 눌러서 인증을 완료하는 것으로, 편의성과 보안성을 모두 제공한다. 또한 FIDO2/WebAuthn의 보편화로, 차세대 인증에서는 OTP를 넘어서 비밀번호 자체가 필요 없는 phishing-resistant 인증이 표준이 될 것으로 전망된다. Apple의 Passkeys, Google의 Passwordless Sign-in 등이 이에 해당한다.
📌 관련 개념 맵 (Knowledge Graph)
| 개념 명칭 | 관계 및 시너지 설명 |
|---|---|
| TOTP | 시간 기반 OTP로, HMAC-SHA1과 시간 카운터를 기반으로 매 30초 마다 새로운 OTP를 생성한다. |
| HOTP | 이벤트 기반 OTP로, HMAC-SHA1과 이벤트 카운터를 기반으로 OTP를 생성하며, 동기화 문제가 있다. |
| MFA | 다요소 인증으로, 비밀번호(지식) + OTP(소유)를 결합하여 보안성을 강화한다. |
| Secret Key | TOTP의根底 핵심으로, 서버와 클라이언트가共有하는秘密情報이며, 유출 되면OTP가突破된다. |
| FIDO2/WebAuthn | 차세대 phishing-resistant 인증으로, 공개키 cryptography를 기반으로하여OTP보다更高的セキュリティを提供する. |
👶 어린이를 위한 3줄 비유 설명
-
OTP는 30초마다 새로 만들어지는 일회용 입장券과 같아요. 만약 입장券을 복사해서小偷가 있어도, 30초가 지나면 그券는 사용할 수 없어서 입장할 수 없어요. 그리고 새로운券를 만들려면 특별한 비밀 정보(secret key)가 필요해요.
-
그런데 만약 그 비밀 정보(secret key)를盗贼가얻으면,盗贼도 새로운券를 만들 수 있어요. 그래서 서버는 비밀 정보를 매우 안전하게保管하고,고객은万一에 대비해 복구券(백업 코드)를 안전한 곳에 백업해둬야 해요.
-
computer의 세계에서도 마찬가지예요. 은행 앱에ログイン하려면 비밀번호(집 비밀번호) plus 30초마다 새로 생성되는 일회용 код(OTP)를 함께 입력해야 하며,万一盗贼가 비밀번호를알아도 OTP가 없으면돈을 찾을 수 없게되어,财产安全을守る 데 도움이 돼요.