모든 처리는 브라우저 내부에서 실행됩니다 — 파일·입력은 서버로 전송되지 않습니다.
base32 공유 시크릿(`JBSWY3DPEHPK3PXP` 같은) 또는 `otpauth://totp/...` URL(2FA 설정 시 서비스가 보여 주는 QR 코드에 자주 인코드되어 있음)을 붙여 넣으세요. 현재의 6자리 코드가 즉시 생성되고, 현재 30초 윈도우 안에서 몇 초가 남았는지를 보여 주는 카운트다운 링이 표시됩니다. 다음 코드도 미리 보기되어, 붙여 넣기 도중에 만료될 코드를 복사하는 것을 피할 수 있습니다.
현재 기기에 인증 앱을 설치하지 않고 TOTP가 필요할 때 사용하세요. 서버 접근 복구, 스크립트 기반 일회성 로그인, 개발 중 2FA 통합 테스트 같은 경우입니다. 보안 트레이드오프에 주의하세요. 인증 앱은 설계상 로그인에 쓰는 기기와는 별개의 보안 기기(휴대폰)에 두는 것이고, 로그인과 같은 브라우저에서 TOTP를 얻으면 그 의미의 상당 부분이 사라집니다. 이 도구는 개발·복구·스크립트 자동화에 쓰고 일상 2FA로는 쓰지 마세요. 코드는 브라우저 밖으로 나가지 않습니다. HMAC-SHA-1 계산은 모두 로컬에서 이루어집니다.
secret: JBSWY3DPEHPK3PXP algorithm: SHA-1 digits: 6 period: 30
Current: 287082 Next: 615847 (20 seconds remaining in current window)
기본값(SHA-1·6자리·30초)은 Google Authenticator·Authy·1Password 등 거의 모든 소비자용 2FA 앱과 일치합니다. RFC 6238은 SHA-256·SHA-512 해시, 7자리·8자리, 60초 간격 같은 변형을 허용하지만, 대부분의 서비스는 클라이언트 호환성이 작은 보안 이득보다 중요하므로 기본값을 유지합니다.
otpauth://totp/GitHub:[email protected]?secret=JBSWY3DPEHPK3PXP&issuer=GitHub&algorithm=SHA1&digits=6&period=30
Issuer: GitHub Account: [email protected] Secret: JBSWY3DPEHPK3PXP Current: 287082
URL 형식(`otpauth://totp/<label>?secret=<base32>&issuer=<name>&...`)은 Google Authenticator의 규약이며 현재 거의 모든 TOTP 발급자가 이를 따릅니다. QR 스캐너로 읽은 URL을 이 도구에 붙여 넣으면 발급자·계정 라벨이 자동으로 채워집니다. QR 스캔 기능이 없는 비밀번호 관리자에 TOTP 시크릿을 추가할 때 유용합니다.
secret (base32): JBSWY3DPEHPK3PXP raw bytes (hex): 48 65 6c 6c 6f 21 de ad be ef
("Hello!" + 4 random bytes)base32(RFC 4648)는 TOTP 시크릿의 전송 형식으로 쓰입니다. 32글자(A~Z·2~7)만 사용하고 대소문자 구분이 없으며 시각적으로 헷갈리는 0·O나 1·I를 포함하지 않습니다. 실제 HMAC은 디코드 후 바이트열에서 동작하며 base32 문자열 자체가 아닙니다. `JBSWY3DPEHPK3PXP`는 디코드하면 단 10바이트입니다. 대부분의 발급자는 20바이트 랜덤 바이트열(base32로 32글자)을 생성합니다.
TOTP(RFC 6238)는 HOTP(RFC 4226)의 카운터를 `floor(unix_timestamp / period)`로 대체한 것입니다. 서버와 클라이언트는 비밀을 공유하고 `HMAC-SHA-1(secret, counter)`를 계산한 뒤 동적 잘라내기로 6자리 10진 코드를 추출합니다. 양쪽이 같은 시각과 같은 비밀을 사용하므로 30초마다 같은 코드에 도달합니다. 서버 측은 한 윈도우(±30초) 차이를 허용하는 것이 일반적이고, 그보다 크게 벌어지면 코드가 갈리며 재동기화가 필요합니다.
HOTP는 코드 생성 때마다 카운터를 증가시키지만 TOTP는 현재 시각을 카운터로 사용합니다. HOTP 코드는 오프라인에서도 생성할 수 있고 윈도우 안이라면 임의 순서로 쓸 수 있지만, 서버 측은 리플레이 탐지와 사용자가 추가로 코드를 생성한 경우의 재동기화를 위해 슬라이딩 카운터를 관리해야 합니다. TOTP에서는 시계를 통해 묵시적으로 양쪽이 카운터에 합의하므로 운영이 단순해집니다. 오늘날의 소비자 2FA는 거의 TOTP이며 HOTP는 RSA SecurID 옛 모델 같은 옛 하드웨어 토큰에 남아 있습니다.
SHA-1 충돌 내성은 깨졌지만(2017년 SHAttered 공격) HMAC-SHA-1은 여전히 안전합니다. 공격 모델이 다르기 때문입니다. 공격자는 비밀을 모르고 태그를 위조해야 하며 같은 평문 해시를 갖는 두 메시지를 찾는 것만으로는 부족합니다. NIST는 SP 800-107r1까지 HMAC-SHA-1을 MAC 용도로 승인했고, RFC 6238도 SHA-1을 기본으로 둡니다. 새 발급자는 SHA-256·SHA-512를 쓸 수 있지만, 인증 앱 모두가 SHA-1을 지원하는 반면 더 긴 변형은 일부만 지원하므로 상호 운용성을 위해 SHA-1이 남아 있습니다.
흔한 원인이 세 가지입니다. **시계 어긋남**: TOTP는 기기 시계가 NTP 진값에서 30초 이내여야 합니다. 설정·시스템 시각을 확인하고 자동 동기화를 켜세요. **패딩**: 일부 서버는 끝의 `=` 패딩을 붙여 base32 시크릿을 반환하고, 다른 서버는 제거합니다. 둘은 동등하게 디코드되어야 하지만 드물게 버그가 있는 구현이 한쪽 형태에서 깨집니다. **알고리즘 불일치**: `algorithm=SHA512`가 포함된 `otpauth://` URL은 SHA-1 코드를 생성하는 앱과 일치하지 않습니다. otpauth 형식이 주어졌다면 그 파라미터를 따르고 덮어쓰지 마세요.
부분적으로 위험합니다. "두 번째 요소"라는 발상은 비밀번호를 도용당해도 별도 기기(휴대폰)가 있어야 로그인이 된다는 것입니다. TOTP 시크릿이 비밀번호와 같은 브라우저 세션에 있으면 멀웨어 감염이나 브라우저 확장 침해로 둘 다 한 번에 탈취당할 수 있습니다. 일상의 계정 보안에서는 TOTP를 별도 기기(휴대폰의 인증 앱, 또는 YubiKey 같은 하드웨어 키)에 두세요. 이 웹 도구는 개발, 스크립트 자동화, 휴대폰을 잃었을 때의 복구, 위협 모델이 다른 스테이징 환경 등에 사용하세요.
대부분의 용도에서 WebAuthn(과 passkey의 UX 계층)이 엄격하게 TOTP보다 안전합니다. TOTP는 서버와 클라이언트가 비밀을 공유하므로 데이터베이스 침해나, 요청을 프록시하는 피싱 사이트로 두 번째 요소가 도용될 수 있습니다. WebAuthn은 공개 키 암호로 origin에 묶이므로 `github.com`용 passkey는 사용자가 속아도 `github.evil.com`에 리플레이될 수 없습니다. TOTP의 오늘의 강점은 보급입니다. 레거시 서비스 대부분이 지원하고, 대응 하드웨어 토큰이 저렴하며, 복구 흐름이 잘 정립되어 있습니다. 신규 시스템은 passkey를 기본으로 두고 TOTP를 폴백으로 삼는 것이 맞고, 반대가 아닙니다.
TOTP(Time-based One-Time Password, RFC 6238, 2011년 5월)는 HOTP(RFC 4226, 2005년)에 작은 래퍼를 씌운 것입니다. 둘 다 공유 비밀에서 HMAC-SHA-1과 동적 잘라내기로 6자리 코드를 추출합니다. 차이는 카운터입니다. HOTP는 코드 생성마다 카운터를 늘리고, TOTP는 `floor(unix_time / 30)`으로 카운터를 계산합니다. 30초 윈도우는 사실상 표준이지만 의무는 아니며 otpauth URL의 period 파라미터로 바꿀 수 있습니다. 대부분의 인증 앱은 30초를 가정하고 다른 값은 무시합니다.
일상 구현에서 중요한 점이 3가지 있습니다. 공유 비밀은 보통 `otpauth://totp/<label>?secret=<base32>&issuer=<name>&algorithm=SHA1&digits=6&period=30` URL이 든 QR 코드를 통해 아웃 오브 밴드로 교환됩니다. QR 코드 자체는 전송 수단일 뿐이며 디코드하면 그냥 base32 시크릿입니다. 서버 측 검증은 시계 어긋남을 허용하기 위해 보통 ±1 윈도우의 드리프트를 인정합니다. 백업 코드(설정 시 사용자가 인쇄해 두는 1회용 예비 코드)는 휴대폰을 잃었을 때의 표준 복구 경로입니다.
TOTP 주변에는 3가지 인접 기술이 있습니다. **HOTP**는 카운터 기반의 조상으로 일부 하드웨어 토큰(RSA SecurID 옛 모델, Yubico의 HOTP 슬롯)에서 지금도 쓰입니다. **SMS 기반 2FA**는 문자 메시지로 코드를 보내며 편리하지만 SIM 스왑 공격에 취약하고 NIST(SP 800-63B)는 고가치 계정에서 폐기를 진행 중입니다. **WebAuthn·passkey**(FIDO2)는 의존 당사자의 origin에 묶이는 공개 키 암호를 사용해 피싱을 구조적으로 불가능하게 만듭니다. 두 번째 요소의 세계는 이쪽으로 가고 있으며 TOTP는 이전이 끝나지 않은 서비스용 롱테일 폴백이 됩니다. YubiKey 같은 하드웨어 토큰은 셋 모두(OATH-HOTP·OATH-TOTP의 TOTP 슬롯, FIDO2)를 지원합니다.
길이와 문자 집합을 조정해 강력한 무작위 비밀번호를 생성합니다. 엔트로피와 강도를 표시하며 브라우저 안에서만 처리합니다.
키와 메시지로 HMAC 서명(SHA-1 / SHA-256 / SHA-384 / SHA-512)을 계산합니다. hex·base64 출력 전환을 지원하며 Web Crypto API로 브라우저 안에서 처리합니다.
RSA 공개키/개인키 쌍을 PEM 포맷(PKCS#1 / PKCS#8)으로 생성합니다. JWT 서명키·SSH 테스트·일회성 암호화에 유용하며, 프로덕션 키는 OpenSSL을 권장합니다.
JSON을 정렬하고 검증합니다. 들여쓰기 출력, 압축 출력, 명확한 에러 위치 표시를 지원합니다.
TOTP는 Web Crypto API로 브라우저 내에서 계산됩니다. 시크릿은 외부로 전송되지 않습니다. 시스템 시계가 크게 어긋나면 서버와 코드가 불일치할 수 있습니다.