01
예제로 일치 상태부터 확인
예제를 누르면 교체 미리보기가 열립니다. 적용하면 검증 모드에 가상의 비밀번호와 일치하는 bcrypt 레코드가 채워집니다. 한 글자를 바꿔 다시 실행하면 불일치 경로도 확인할 수 있습니다.
- 적용 전에는 입력을 바꾸지 않으며 실행 취소는 이전 입력과 결과를 함께 복원합니다.
Hash & Crypto Helpers
비밀번호 해시 생성저장된 조건으로 정확하게 검증
테스트 비밀번호로 해시를 생성하거나 검증 모드에서 기존 레코드를 확인하세요.
비밀번호 해시 생성
테스트 비밀번호
해시 레코드
테스트 값만 사용하세요. 비밀번호는 페이지와 Worker 메모리에서 처리하며 전송하거나 브라우저 저장소에 기록하지 않습니다.
옵션
테스트 기본 비용은 10, 허용 범위는 4–14입니다. 작업량은 2^cost로 증가하며 운영 환경 권장값이 아닙니다.
랜덤: 매번 16바이트. 고정: bcrypt 16바이트, 나머지 8–64바이트. 공백과 0x 접두사 없이 입력하세요.
bcrypt와 Argon2id는 인코딩 문자열을 사용합니다. scrypt/PBKDF2는 HeyUtils JSON이며 모든 프레임워크의 공통 형식은 아닙니다.
테스트 비밀번호를 입력하고 작업을 실행하세요.
테스트 계정이 라이브러리 교체 후 인증되지 않는다면 비밀번호 바이트와 저장 형식부터 확인하세요. 비밀번호 해시 생성 도구는 솔트와 비용을 함께 남겨 두 구현의 계산 조건을 맞추는 데 쓰입니다.
검증은 입력한 레코드에서 알고리즘과 매개변수를 읽습니다. 생성 옵션을 바꾸어도 검증할 레코드의 조건은 덮어쓰지 않습니다. 알려진 예제로 먼저 일치 여부를 확인하면 잘못된 입력과 형식 차이를 구분하기 쉽습니다.
비밀번호 해시 생성 도구를 쓰는 이유
솔트가 결과를 바꾸는 과정 확인
비밀번호 해시 생성 도구의 랜덤 모드는 실행마다 새 16바이트 솔트를 만듭니다. 같은 비밀번호에서도 다른 레코드가 나오는 이유를 직접 확인하고, 고정된 16진수 솔트로 바꾸면 재현 가능한 테스트를 만들 수 있습니다.
불일치와 형식 오류를 구분
불일치는 저장된 조건으로 계산을 마쳤지만 값이 다른 상태입니다. 읽을 수 없는 형식이나 너무 높은 비용은 계산 전에 오류로 표시합니다. 따라서 비밀번호를 수정할지 레코드를 다시 준비할지 판단할 수 있습니다.
검증 조건을 재현하는 세 가지 요령
02
솔트 입력은 바이트로 생각하기
생성 모드의 고정 솔트는 일반 단어가 아니라 16진수 바이트입니다. bcrypt는 정확히 16바이트, 다른 알고리즘은 8–64바이트를 받습니다. 랜덤 모드에서는 실행할 때마다 솔트가 달라집니다.
- 결과에 나온 실제 솔트를 고정 솔트로 사용하면 같은 계산을 재현할 수 있습니다.
03
결과가 최신인지 확인하고 내보내기
Ctrl/Cmd + Enter로 선택한 작업을 실행합니다. 입력이나 옵션을 바꾸면 계산이 취소되고 이전 결과의 복사와 다운로드가 비활성화됩니다. 생성 성공 또는 검증 일치 후에 내보낼 수 있습니다.
- 계산 중 직접 중지할 수 있고 15초를 넘으면 Worker가 종료됩니다.
알고리즘과 저장 조건을 함께 다루기
실제 엔진으로 네 가지 방식 실행
bcrypt 검증과 생성, scrypt, Argon2id, PBKDF2-HMAC-SHA-256을 지원합니다. 매번 한 알고리즘만 실행해 독립된 비밀번호 해싱 테스트를 만들며, 여러 알고리즘을 동시에 돌려 속도 순위를 매기지는 않습니다.
검증에 필요한 정보를 레코드에 포함
bcrypt는 비용 인수와 솔트가 들어 있는 문자열을 사용합니다. Argon2id는 v19 PHC로 저장하며 scrypt와 PBKDF2는 parameters, saltHex, hashHex를 포함한 버전 지정 HeyUtils JSON을 사용합니다.
과도한 계산을 실행 전에 차단
가져온 레코드의 비용도 같은 한도로 검사합니다. 표시되는 밀리초는 현재 기기의 한 번 실행 시간이며 처음에는 엔진 로딩 시간이 포함될 수 있습니다. 서버 처리량이나 동시 로그인 성능을 나타내는 지표로 해석하면 안 됩니다.
지원 범위와 실제 제한
- 공백과 Unicode 차이를 유지
- 비어 있지 않은 한 줄의 테스트 비밀번호만 받으며 UTF-8 기준 1024바이트까지 허용합니다. bcrypt는 72바이트를 넘으면 거부합니다. 자동 자르기, 정규화, 사전 해싱을 하지 않고 잘못된 Unicode와 줄바꿈은 오류로 처리합니다.
- 검증에도 동일한 비용 상한 적용
- bcrypt 비용은 4–14, scrypt ln은 10–16이며 r=8, p=1입니다. Argon2id는 m=8–65536 KiB, t=1–6, p=1–4이며 m≥8p, m×t≤131072를 만족해야 합니다. PBKDF2는 1–1000000회입니다.
- 지정된 레코드 형식만 해석
- bcrypt $2a$, $2b$, $2y$, m,t,p 순서의 Argon2id v19, 자체 scrypt/PBKDF2 JSON을 지원합니다. 최대 8192자이며 다른 프레임워크 형식, Argon2i/d, v16, pepper, 추가 데이터는 자동 처리하지 않습니다.
- 솔트와 파생값 길이를 제한
- 랜덤 솔트는 16바이트입니다. 고정 솔트는 공백이나 접두사 없는 16진수이며 bcrypt 16바이트, 나머지 8–64바이트입니다. bcrypt 외에는 32바이트를 생성하고 16–64바이트 태그를 검증합니다. PHC Base64는 패딩 없이 정규 형식이어야 합니다.
- 테스트와 운영 설정을 구분
- 기본 비용은 운영 환경 보안 권장값이 아닙니다. 복호화, 비밀번호 복구, 파일 입력, 일괄 시도, 강도 평가는 제공하지 않습니다. 교체 전 비밀번호는 한 번의 실행 취소를 위해 다음 편집·실행·페이지 이탈까지 메모리에 남습니다.
비밀번호 해시 생성 관련 질문
제 비밀번호는 안전한가요? 서버로 전송되나요?
계산에 사용한 입력은 서버로 전송하거나 브라우저 저장소에 기록하지 않습니다. 다만 실제 계정 비밀번호 대신 테스트 값만 사용하세요. 비밀번호 표시, 클립보드, 다운로드와 실행 취소용 메모리는 사용자가 선택한 동작에 따라 남을 수 있으므로 실제 비밀정보를 넣을 이유가 없습니다.
어떤 비용 인수(라운드)를 사용해야 하나요?
여기서는 bcrypt 비용 10을 테스트 기본값으로 사용하며 4–14를 허용합니다. 비용을 높이면 작업량도 커지므로 무조건 최댓값을 고르는 방식은 적절하지 않습니다. 운영 환경에서는 해당 라이브러리와 서버, 예상 동시 요청, 허용 지연을 기준으로 별도 측정해 결정하세요.
같은 비밀번호가 매번 다른 bcrypt 해시를 생성하는 이유는 무엇인가요?
실행마다 새 랜덤 솔트를 쓰기 때문입니다. 각 레코드는 자기 솔트를 포함하므로 서로 다른 해시여도 같은 비밀번호를 검증할 수 있습니다. 반복 가능한 비교가 필요할 때만 고정 솔트와 동일한 비밀번호 바이트, 알고리즘 및 매개변수를 사용하세요.
검증에서 제 해시가 유효하지 않다고 나오는 이유는 무엇인가요?
전체 문자열이 잘렸는지, 접두사와 인코딩이 지원되는지 먼저 확인하세요. 비용이 도구의 상한을 넘는 레코드도 거부됩니다. scrypt와 PBKDF2는 이 페이지의 JSON 형식이어야 합니다. 원래 시스템이 pepper나 사전 해싱을 사용했다면 그 환경에서 검증해야 합니다.
bcrypt에 비밀번호 길이 제한이 있나요?
bcrypt의 경계는 72바이트이며 글자 수가 아닙니다. UTF-8에서 한글과 이모지는 여러 바이트를 차지하므로 짧게 보여도 넘을 수 있습니다. 이 도구는 생성과 검증 모두에서 초과 입력을 오류로 처리하며 뒷부분을 잘라 성공으로 보이게 하지 않습니다.
궁금한 점이 남았나요?