TOTP 생성기 — 2FA 코드 생성기와 otpauth QR 만들기

Base32 시크릿을 카운트다운과 함께 실시간 2FA 코드로 바꾸고, 인증 앱용 otpauth:// QR 코드를 만들거나 기존 URI를 읽으세요.

시크릿 키(Base32)

공백과 소문자도 괜찮습니다. 160비트 키.

알고리즘

자릿수

주기

현재 코드

— — —

이전 — · 다음 —

코드는 기기 시계에 따라 달라집니다. 코드가 거부되면 시계가 자동으로 설정되어 있는지 확인하세요. 대부분의 서버는 이전 코드와 다음 코드도 허용합니다.

otpauth:// URI와 QR 코드

발급자

계정 이름

otpauth://totp/Example%20Inc:jane%40example.com?secret=GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ&issuer=Example%20Inc&algorithm=SHA1&digits=6&period=30

Google Authenticator, Microsoft Authenticator, 1Password, Authy 등 TOTP 앱으로 스캔하세요. 많은 앱이 SHA-256/512와 8자리를 무시하므로, 양쪽을 모두 관리하는 경우가 아니라면 기본값을 유지하세요.

otpauth:// URI 읽기

URI 붙여 넣기(예: QR 스캐너에서 복사한 것)

시크릿과 코드는 브라우저에만 남으며, 전송되거나 저장되지 않습니다. TOTP 시크릿은 비밀번호처럼 다루세요. 시크릿을 가진 사람은 누구나 내 코드를 만들 수 있습니다. 모든 무료 도구 보기.

문제를 발견하셨거나 개선할 점이 있나요? 모든 메시지를 읽고 빠르게 고칩니다.

이 TOTP 생성기는 Google Authenticator, Microsoft Authenticator, 1Password 등 인증 앱과 똑같은 시간 기반 일회용 코드를 만듭니다. Base32 시크릿을 입력하면 현재 6자리 또는 8자리 코드가 카운트다운과 함께, 이전·다음 코드와 나란히 표시됩니다. 애플리케이션에 2단계 인증을 추가하는 개발자를 위해 만들었습니다. 시크릿을 생성하고, 사용자가 스캔할 otpauth:// URI와 QR 코드를 만들고, 서버가 받아야 할 코드를 제대로 받는지 확인하세요.

코드는 RFC 6238(TOTP)과 RFC 4226(HOTP)에 따라 WebCrypto HMAC 함수로 브라우저에서 계산되며, 구현은 두 RFC의 공식 테스트 벡터로 테스트되었습니다. 아무 데도 전송되지 않습니다. 그래도 TOTP 시크릿은 비밀번호만큼 민감합니다. 시크릿을 가진 사람은 누구나 유효한 코드를 만들 수 있습니다. 테스트 계정과 연동 작업에 쓰고, 실제 계정의 인증 앱 대용으로 쓰지 마세요.

사용 방법

Base32 시크릿을 붙여 넣거나 새 무작위 시크릿을 누르세요. 공백과 소문자도 괜찮습니다.
서버가 다른 값을 쓰지 않는다면 알고리즘, 자릿수, 주기는 SHA-1, 6, 30초 그대로 두세요.
현재 코드를 확인하세요. 링은 코드가 몇 초 더 유효한지 보여 줍니다. 버튼으로 복사하세요.
발급자와 계정 이름을 입력해 otpauth:// URI를 만든 뒤, 인증 앱으로 QR 코드를 스캔해 둘 다 같은 코드를 보여 주는지 확인하세요.
기존 설정을 살펴보려면 otpauth:// URI를 읽기 도구에 붙여 넣고 불러오기를 누르세요.

자주 묻는 질문

TOTP 코드는 어떻게 작동하나요?

서버와 인증 앱이 비밀 키를 공유합니다. 30초마다 둘 다 그 키와 1970년 1월 1일 이후 지난 30초 단위 수로 HMAC-SHA1을 계산하고, 결과를 6자리로 줄입니다. 양쪽이 같은 시크릿과 같은 시계를 쓰므로 통신하지 않고도 같은 코드를 얻습니다. 이것이 RFC 6238이고, 기반이 되는 카운터 기반 알고리즘은 HOTP, RFC 4226입니다.

TOTP 코드가 작동하지 않는 이유는 무엇인가요?

단연 가장 흔한 원인은 시계 오차입니다. 약 30초 넘게 차이 나면 기기가 다른 시간 단위에 있게 됩니다. 기기와 서버 모두 시간을 자동으로 동기화하도록 설정하세요. 다른 원인으로는 시크릿 오타(Base32는 A–Z와 2–7만 쓰므로 O, I, 0, 1, 8은 나오지 않습니다), 또는 서버가 8자리, SHA-256, 60초 주기 같은 다른 설정을 기대하는 경우가 있습니다.

TOTP의 SHA-1은 안전하지 않나요?

안전합니다. 알려진 SHA-1 약점은 해시가 같은 두 입력을 만들 수 있는 충돌 공격입니다. TOTP는 비밀 키와 함께 HMAC 안에서 SHA-1을 쓰며, 이 구조는 충돌 저항성에 의존하지 않아 여전히 안전합니다. 거의 모든 인증 앱이 지원하기 때문에 SHA-1이 여전히 기본값입니다.

otpauth:// URI란 무엇인가요?

2FA 설정 QR 코드 안에 든 텍스트로, 원래 Google Authenticator가 정의한 Key Uri Format을 따릅니다: otpauth://totp/Issuer:account?secret=BASE32SECRET&issuer=Issuer, 선택적으로 algorithm, digits, period 매개변수가 붙습니다. QR 코드를 스캔하면 이 문자열이 앱에 전달될 뿐입니다. QR 코드나 URI를 본 사람은 시크릿을 가진 셈이므로 설정 화면을 민감하게 다루세요.

TOTP 시크릿은 얼마나 길어야 하나요?

RFC 4226은 최소 128비트를 요구하고 160비트, 즉 Base32 32자를 권장합니다. 새 무작위 시크릿 버튼은 crypto.getRandomValues로 160비트를 생성합니다. 많은 오래된 서비스가 80비트(16자) 시크릿을 발급하는데, 작동은 하고 이 도구가 경고를 표시하지만, 새 시스템은 최소 160비트를 써야 합니다.

모든 인증 앱이 8자리와 SHA-256을 지원하나요?

아니요. otpauth 형식은 SHA256, SHA512, 8자리, 다른 주기를 허용하지만, 일부 앱은 이 매개변수를 무시하고 항상 SHA-1, 6자리, 30초 코드를 만들어 결과가 맞지 않게 됩니다. 서버를 직접 관리한다면 기본값이 안전한 선택입니다. 기본값이 아닌 설정을 출시하기 전에 사용자가 쓸 법한 앱으로 이 페이지의 QR 코드를 스캔해 코드를 비교하세요.

내 애플리케이션에 TOTP 추가하기

• 서버에서 사용자마다 최소 160비트의 무작위 시크릿을 생성하고, 해시가 아니라 암호화해서 저장하세요. 서버가 코드를 계산하려면 원본이 필요합니다.

• otpauth:// URI를 QR 코드로 보여 주고, 스캔할 수 없는 사용자를 위해 Base32 시크릿도 텍스트로 보여 주세요.

• 2FA를 활성화하기 전에 유효한 코드를 한 번 입력하게 해서, 스캔에 실패해도 사용자가 잠기지 않게 하세요.

• 검증할 때는 현재 코드와 보통 앞뒤 한 단계(여기 표시되는 이전·다음 코드)까지 받아 시계 오차를 흡수하고, 재사용 공격을 막기 위해 그 범위에서 이미 쓰인 코드는 거부하세요.

• 시도 횟수를 제한하세요. 6자리 코드는 경우의 수가 백만 개뿐이라 무제한으로 추측하면 뚫립니다.

• 등록할 때 일회용 복구 코드를 발급하고, 비밀번호처럼 해시해서 저장하세요.

TOTP와 SMS 코드, 푸시, 패스키 비교

TOTP는 SIM 스와핑 공격과 SS7 취약점으로 가로챌 수 있는 SMS 코드보다 훨씬 강력하며, 전화번호 없이 오프라인에서도 작동합니다. 약점은 피싱입니다. 그럴듯한 가짜 로그인 페이지가 코드를 요구한 뒤 30초 안에 실제 사이트로 전달할 수 있습니다.

푸시 승인은 편리하지만 공격자가 사용자가 승인을 누를 때까지 요청을 보내는 "MFA 피로" 공격을 부릅니다. 패스키와 하드웨어 보안 키(FIDO2/WebAuthn)는 브라우저가 자격 증명을 실제 사이트의 도메인에 묶기 때문에 설계상 피싱에 강한 유일한 일반적인 방법입니다. 패스키를 먼저 제공하고 TOTP를 널리 지원되는 대안으로 두는 것이 합리적입니다.