랜덤 토큰 생성기

Math.random 으로 토큰을 만들면 실제로 뚫립니다

이것은 이론적인 걱정이 아니라 실제로 계정이 털리는 취약점입니다. Math.random은 빠른 난수를 뽑는 함수일 뿐 암호학적 안전성을 목표로 설계되지 않았습니다. 자바스크립트 엔진들이 쓰는 알고리즘은 내부 상태를 가지고 값을 순서대로 만들어내는데, 연구자들은 출력된 값 몇 개만 관찰하면 내부 상태를 복원해 이후에 나올 값을 그대로 계산할 수 있음을 시연했습니다.

비밀번호 재설정 토큰을 Math.random으로 만들었다고 해봅시다. 공격자는 자기 계정으로 재설정을 여러 번 요청해 토큰 샘플을 모으고, 내부 상태를 복원한 뒤, 관리자 계정의 재설정을 요청해 나올 토큰을 미리 계산합니다. 메일을 가로챌 필요조차 없습니다. 이 도구가 crypto.getRandomValues 만 쓰는 이유가 이것입니다.

몇 비트면 충분한가 — 프리셋별 실제 수치

토큰의 강도는 길이가 아니라 엔트로피(비트)로 따집니다. 문자 후보가 62종인 40자 토큰은 62의 40제곱 가지, 약 238비트입니다. 결과 아래 통계에 이 값이 표시되고 약함·보통·강함·매우 강함으로 등급이 매겨집니다.

기준을 잡자면 세션 ID는 최소 128비트가 통용됩니다. 그 이상은 늘려도 실질적인 안전도 차이가 없고 쿠키만 길어집니다. 반대로 40비트 미만은 요즘 하드웨어로 전수 대입이 현실적인 영역이라 비밀 값으로 쓰면 안 됩니다.

숫자 OTP 6자리는 그 자체로 안전할 수 없습니다

6자리 숫자는 100만 가지뿐입니다. 자동화 도구로 초당 수백 번 시도하면 현실적인 시간 안에 다 넣어볼 수 있는 숫자입니다. 여기서 자릿수를 늘리는 것은 답이 아닙니다 — 사용자가 문자로 받은 번호를 손으로 옮겨 적어야 하니까요.

그래서 OTP의 안전성은 토큰 자체가 아니라 그것을 감싸는 규칙에서 나옵니다. 국내 서비스가 문자 인증번호를 3분 유효 · 5회 실패 시 잠금 · 재발송 횟수 제한으로 운영하는 것은 관행이 아니라 필수 조건입니다.

• 유효시간을 짧게 두세요. 3~5분이면 충분합니다.
• 시도 횟수를 제한하고 초과하면 코드를 폐기하세요. 새 코드를 받게 해야지 계속 맞춰보게 두면 안 됩니다.
• 전화번호·IP 단위로 발송 횟수를 제한하세요. 안 그러면 문자 요금 폭탄 자체가 공격 수단이 됩니다.
• 한 번 쓴 코드는 즉시 무효화하세요.

접두어를 붙이는 진짜 이유

접두어 칸에 sk_live_ 처럼 넣으면 모든 토큰 앞에 붙습니다. 보기 좋으라고 있는 기능이 아닙니다. 접두어는 유출 사고에서 두 가지 일을 합니다.

첫째, 어디 키인지 즉시 알 수 있습니다. 로그나 채팅에서 정체불명의 40자 문자열을 발견하면 추적에 반나절이 걸리지만, sk_live_ 로 시작하면 어느 서비스의 운영 키인지 한눈에 보입니다. 둘째, 자동 탐지가 가능해집니다. 깃허브의 시크릿 스캐닝이나 사내 커밋 훅은 이런 고정 패턴을 찾아 경고합니다. live와 test를 접두어로 구분해 두면 운영 키를 테스트 코드에 넣는 사고도 걸러집니다.

만든 다음이 더 중요합니다

이 도구는 생성된 토큰을 저장하지 않습니다. 서버로 보내지도 않고 브라우저에도 남기지 않습니다 — 남는 것은 프리셋·길이 같은 설정뿐입니다. 새로고침하면 토큰은 사라지므로, 필요한 값은 그 자리에서 안전한 곳으로 옮기세요.

• 소스코드에 상수로 박지 마세요. 환경변수나 비밀 관리 도구에 두고 읽어 쓰세요.
• .env 파일은 .gitignore 에 넣으세요. 이미 커밋했다면 히스토리에 영원히 남습니다 — 파일을 지우는 것으로 끝나지 않고 키를 폐기하고 새로 발급해야 합니다.
• 채팅·이슈·스크린샷에 붙여넣은 순간 유출로 간주하세요. 나중에 삭제해도 이미 백업과 알림 메일에 남았습니다.
• 서버에 저장할 때는 토큰 자체 대신 해시를 저장하는 방법을 검토하세요. DB가 털려도 원본 토큰은 나가지 않습니다.
• 개수를 여러 개로 두면 목록이 나오고 전체 복사·저장이 됩니다. 여러 환경에 뿌릴 키를 한 번에 만들 때 유용하지만, 저장한 txt 파일을 지우는 것까지가 작업입니다.