HOTP와 TOTP는 공유 비밀을 사용하는 HMAC 기반 OTP 계열이지만 moving factor가 다릅니다. HOTP는 인증기와 검증기가 동기화해야 하는 이벤트 카운터 C를 쓰고, TOTP는 시간 기준과 step X로 계산한 T=floor((현재 Unix time−T0)/X)를 사용합니다.
코드 숫자가 바뀌는 기준 입력이 달라진다는 뜻이지 매번 서로 다른 숫자가 반드시 나온다는 뜻은 아닙니다. 시간 오차·counter drift를 허용하는 검증 window도 별도 정책입니다. 계산 상황은 교육용으로 직접 만들었습니다.
두 방식은 움직이는 입력값을 다르게 정의합니다
일회용 비밀번호(OTP) 문제에서 비밀키 K와 계산 방식만 외우면 HOTP와 TOTP를 구분하기 어렵습니다. RFC 4226의 HOTP는 비밀키 K와 counter C로부터 값을 계산합니다. 이 8바이트 counter가 moving factor이며 생성기와 검증기 사이에 동기화돼야 합니다. 단말에서 버튼을 눌러 다음 OTP를 만드는 사건이 발생할 때 counter가 전진합니다. 서버는 마지막으로 확인한 counter와 입력값을 맞춰야 하므로 단말과 서버 상태가 어긋날 수 있습니다.
RFC 6238의 TOTP는 HOTP 계산에서 counter C 대신 현재 시간을 바탕으로 만든 시간 계수 T를 사용합니다. T=floor((현재 Unix time−T0)/X)로 정의하며 X는 시간 step입니다. T0가 0이고 X가 30초라면 Unix time 59초는 T=1, 60초는 T=2가 됩니다. 따라서 단말에서 버튼을 누르지 않아도 시계가 다음 구간에 들어가면 입력 계수가 바뀔 수 있습니다. 기본 X=30초는 표준의 기본값 권고이고, 각 배포가 정한 window나 시간 오차 허용과 동일한 설정이라고 단정하면 안 됩니다.
| 방식 | 계산에 넣는 moving factor | 가상 사건 전 | 가상 사건 후 | 무엇이 바뀌었나 |
|---|---|---|---|---|
| HOTP | 공유 K와 이벤트 counter C | 단말 C=40, 서버 C=40 | 단말에서 두 번 생성해 C=42, 서버는 C=40 | 생성 이벤트 수가 앞서 서버 동기화가 어긋남 |
| TOTP | 공유 K와 시간 step T | Unix time 59초, X=30초 → T=1 | Unix time 60초 → T=2 | 시간이 경계 60초를 넘어 계수가 증가 |
버튼 이벤트와 시계 경계의 결과를 다르게 풉니다
HOTP 단말에서 버튼을 두 번 눌러 OTP 생성을 진행했지만 두 코드를 제출하지 않았다고 합시다. 생성기 counter가 C=40에서 C=42로 앞서고, 검증 서버의 마지막 counter는 40일 수 있습니다. 검증 정책은 미래 counter의 제한된 범위를 찾아 동기화할 수 있지만, 허용 look-ahead를 너무 넓히면 공격자가 시도할 수 있는 입력 범위와 계산 부담이 증가합니다. 실제 허용 범위는 구현·정책에 따릅니다. HOTP의 원리 답은 ‘버튼 누름으로 생긴 이벤트 counter가 이동한다’이며 ‘초마다 자동 변경’이 아닙니다.
TOTP는 같은 K를 쓰더라도 counter 대신 현재 시간을 정해진 단위 X로 나눈 계수 T에 넣습니다. 시간 값이 59초일 때 1이고 다음 초인 60초가 되면 2입니다. 서버와 인증기 시계가 한 step 이상 어긋나거나 요청 전송이 경계에 걸리면 계산한 T가 맞지 않을 수 있습니다. 검증기는 일정한 과거·미래 구간을 허용할 수 있지만 그 구간은 정책으로 정하며, 창을 넓히면 코드가 받아들여지는 시간 범위도 커집니다. 시간을 정확히 동기화해야 한다는 설명과 허용 window 정책을 구분합니다.
두 방식 모두 숫자 OTP는 HMAC 출력의 일부를 잘라 사람이 입력하기 쉬운 형태로 만듭니다. 따라서 moving factor가 달라졌다고 잘린 짧은 숫자 코드가 반드시 다른 값이라고 단정할 수 없습니다. 서로 다른 계산 입력에서도 같은 숫자가 우연히 나올 수 있습니다. 서술 답안에서는 입력 계수가 어떻게 산출되는지를 설명하고 실제 코드 숫자의 차이를 보장하지 않는 편이 정확합니다.
문제의 단서를 카운터·시간·검증 정책으로 나눕니다
- 문제에 버튼·생성 횟수·counter가 나오면 HOTP의 이벤트 계수 C를 표시합니다.
- Unix time·T0·초 단위 간격 X가 나오면 TOTP의 시간 계수 T를 계산합니다.
- 생성기와 검증기 값이 다르면 어떤 상태가 전진 또는 지연했는지 기록합니다.
- 허용 window와 counter resynchronization은 정식 moving factor와 분리합니다.
- 짧은 숫자가 같은지보다 HMAC 입력값·계수의 기준을 먼저 답합니다.
기존 정보보호론 인증·SSO 글은 TOTP와 시간 오차를 넓게 소개합니다. 여기서는 해당 개념을 반복하는 대신 HOTP event counter와 TOTP time factor를 같은 형식의 표에 맞춰 비교했습니다. HOTP와 TOTP 모두 HMAC 기반 구조와 비밀키의 안전한 저장이 중요하지만, 검증기가 어디까지 앞선 카운터를 허용하거나 시계 오차를 허용하는지는 제품·정책에서 확인해야 합니다. 표준의 계산 정의와 실제 서비스의 실패 복구 절차는 같은 규칙이 아닙니다.
짧은 OTP가 언제나 매번 다른 숫자라고 외우지 않습니다
첫 번째 실수는 HOTP를 ‘시간이 지나면 바뀌는 암호’로 설명하는 것입니다. HOTP의 moving factor는 서버와 생성기가 맞춰야 하는 이벤트 counter입니다. 두 번째 실수는 TOTP를 ‘매 30초마다 코드가 항상 달라진다’고 보장하는 것입니다. 표준 기본 step에서 T가 구간마다 바뀌어도 truncation된 출력값이 우연히 반복될 가능성을 배제하지 않습니다. 세 번째는 서버 검증 window를 알고리즘 정의 자체와 섞는 것입니다. 계산 계수와 운영상 허용 범위를 구분해야 합니다.
주어진 숫자로 계수만 먼저 계산해 봅니다
회상 연습: HOTP 단말이 생성 이벤트를 세 번 더 진행했고 서버 counter는 그대로입니다. TOTP에서는 T0=0, X=30초, 현재 시간이 60초입니다. 각 방식의 현재 moving factor는 무엇이며 서버와 비교할 추가 조건은 무엇인가요? HOTP는 초기 counter에서 3 증가한 값이며 서버가 허용하는 resynchronization/look-ahead 범위를 확인합니다. TOTP는 floor(60/30)=2이고 서버·인증기 시각 차이 및 허용 step window를 확인합니다. 이 예시는 학습용으로 직접 만든 자료이며 실제 시험 출제 문항 또는 집중 180제 판매 카드가 아닙니다. 상품 구성은 /decks/security#focus-180에서 확인할 수 있습니다.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
HOTP 단말은 생성 이벤트를 세 번 더 진행했지만 서버 counter는 그대로다. TOTP는 T0=0, X=30초이고 현재 시간이 60초다. moving factor와 검증기가 추가로 확인할 조건을 구분하세요.
정답과 해설 확인
HOTP의 단말 counter는 초기값보다 3 앞서 있어 서버의 허용 resynchronization/look-ahead 범위를 확인합니다. TOTP는 floor(60/30)=2이며 서버와 단말의 시간 동기화와 허용 step window를 확인합니다.HOTP의 moving factor는 event counter C이고 TOTP의 T는 시간에서 계산합니다. 서버의 허용 범위는 이 계수 정의와 별도 검증 정책이며 출력 숫자만으로 동일성을 판단할 수 없습니다.