안전한 비밀번호 & API 키 생성기

생성된 비밀번호가 어딘가로 전송되나요?

전송되지 않습니다. 생성은 전적으로 브라우저 안에서 이루어지며 값이 네트워크로 나가지 않습니다.

난수는 운영체제의 안전한 난수원에 연결된 crypto.getRandomValues() 로 얻습니다. Math.random() 과 달리 예측 가능한 시드에서 나오지 않으므로 암호학적 용도에 적합합니다. 다만 아주 민감한 자격증명이라면 온라인 도구 대신 비밀번호 관리자에 내장된 생성기나 오프라인 도구를 쓰는 것이 원칙적으로 더 안전합니다.

패스프레이즈가 정말 비밀번호보다 안전한가요?

길이만 충분하다면 그렇습니다.

amber-glacier-tundra-quartz 는 27자이고 200단어 목록에서 4개를 고르는 방식이라 약 30비트의 엔트로피를 가집니다. 단어 수를 6개로 늘리면 약 46비트가 되고, EFF의 7,776단어 목록을 쓰면 6단어로 77비트에 이릅니다.

핵심은 단어를 무작위로 골라야 한다는 점입니다. 좋아하는 노래 가사나 속담에서 단어를 뽑으면 엔트로피가 급격히 떨어집니다. 사람이 고르는 순간 무작위성이 사라지기 때문입니다.

예상 소요 시간이 '사실상 불가능'인데 정말 안전한가요?

그 계산은 비밀번호 자체를 추측하는 무차별 대입만 가정한 값입니다.

현실의 계정 탈취는 대부분 다른 경로로 일어납니다. 다른 사이트에서 유출된 비밀번호를 그대로 시도하는 크리덴셜 스터핑, 피싱, 기기 감염된 악성코드가 대표적입니다. 아무리 강한 비밀번호도 여러 사이트에서 재사용하면 무의미합니다.

따라서 강한 비밀번호 생성은 기본이고, 여기에 사이트마다 다른 비밀번호와 2단계 인증을 함께 써야 실제 안전성이 확보됩니다.

API 키에는 어떤 형식이 좋나요?

Base62(영문 대소문자+숫자)가 무난합니다. URL·헤더·환경변수 어디에 넣어도 이스케이프가 필요 없고 더블클릭으로 전체 선택이 잘 됩니다.

32바이트(256비트)면 충분히 안전합니다. sk_live_ 같은 접두사를 붙이면 유출된 키를 발견했을 때 어느 서비스의 어떤 환경 키인지 바로 알 수 있어 대응이 빨라집니다. 실제로 GitHub의 시크릿 스캐닝은 이런 접두사 패턴을 이용해 유출을 자동 탐지합니다.