비밀번호 재설정 토큰의 엔트로피를 어떻게 설명하고 점검하나요?

엔트로피는 문자열 길이가 아니라 공격자가 모르는 후보 공간과 실제 시도 예산으로 설명하겠습니다. 32바이트를 균등한 CSPRNG에서 얻으면 이상적으로 2^256개 후보가 있지만, 8비트 seed로 결정되는 생성기라면 공격자는 256개 seed만 시험하면 됩니다. 따라서 OS가 제공하는 예측 불가능한 난수원, 안전한 표현, 만료·단일 사용·rate limit을 함께 점검해야 합니다.

예를 들어 6자리 숫자 코드는 후보가 10^6개뿐입니다. 계정별로 5번만 허용하면 단순 추측의 대략적인 성공 상한은 5/10^6이지만, 온라인 제한이 우회되거나 여러 계정에 분산되면 예산이 달라집니다. URL 토큰을 43자 base64url이라고 부르는 것보다 원시 바이트 수와 난수원, URL·Referer·분석 로그 노출을 확인하는 것이 중요합니다. 서버 DB에는 토큰 원문 대신 해시를 저장하고, 소비 시 만료·미사용 조건과 비밀번호 변경을 원자적으로 묶겠습니다.

발급 후에는 만료 시각, 계정·용도 결합, 재발급 시 이전 토큰 무효화, 동시 소비 한 번만 성공하는지 확인합니다. 메일함이나 URL이 노출되면 강한 난수도 탈취될 수 있으므로 추가 인증과 사용자 알림이 필요할 수 있습니다. 엔트로피 계산은 보안의 일부일 뿐이며, 링크가 신뢰되지 않은 host로 생성되거나 성공 응답이 계정 존재를 노출하면 다른 경계가 약해집니다.

하나의 reset trace를 보면 계산의 의미가 드러납니다. 발급 시 32바이트 CSPRNG 원문 T를 만들고 DB에는 H(T), user, purpose, expires_at만 저장한 뒤 링크에는 T를 한 번만 넣습니다. 6자리 코드는 N=10^6이고 q=5라 단순 추측 상한은 5/10^6이지만, 32바이트 토큰은 이상적으로 N=2^256이라 같은 q에서 훨씬 넓은 공간을 가집니다. 사용 요청이 오면 hash lookup과 만료 확인을 한 트랜잭션에서 수행하고 consumed_at IS NULL 조건으로 한 경쟁 요청만 성공시킵니다. 재발급 때는 이전 미소비 토큰을 무효화해 메일 지연 링크가 살아 있지 않게 합니다. DB가 읽혀도 원문이 없으면 바로 소비할 수 없지만, 메일함·URL·Referer가 노출되면 이 보호는 충분하지 않으므로 HTTPS와 referrer 정책, 사용자 알림도 별도로 봅니다. 8비트 seed 생성기는 32바이트처럼 보여도 256개 상태만 탐색하면 되므로 길이만으로 엔트로피를 주장할 수 없습니다.