Bcrypt 생성기 — Bcrypt로 비밀번호 해시 생성 및 검증

원하는 cost로 비밀번호를 bcrypt 해시하고, 비밀번호가 bcrypt 해시와 일치하는지 확인하고, 해시의 각 부분이 무엇을 뜻하는지 알아보세요.

bcrypt 해시 생성

비밀번호

72바이트 중 28바이트(UTF-8).

비용 계수: 10 (2^10 = 1,024라운드)

한 단계 올릴 때마다 시간이 두 배가 됩니다. 로그인 해시에는 보통 10–12를 씁니다.

비밀번호를 해시와 대조해 검증

Bcrypt 해시

확인할 비밀번호

해시 구조

버전	$2b$	2b — 255바이트보다 긴 비밀번호 문제를 고친 OpenBSD의 2014년 수정판. 현재 bcrypt(C/Python/Node)의 기본값입니다.
비용	10	2^10 = 1,024회 키 확장 라운드
솔트	O.0JDwgDTALNNPsTWXP1YO	22자 = 무작위 128비트, bcrypt Base64
해시	2o9FuEFCZZMBsOKg910t7.RrUqVQsmW	31자 = 192비트 출력 중 184비트

비밀번호는 bcryptjs를 사용해 브라우저에서 해싱되고 검증됩니다. 아무것도 전송, 저장, 기록되지 않습니다. 그래도 실제 운영 중인 비밀번호는 어떤 웹 페이지에도 붙여 넣지 마세요. 모든 무료 도구 보기.

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

이 bcrypt 생성기는 cost 4~15로 비밀번호를 bcrypt 해시하고, 비밀번호가 기존 bcrypt 해시와 일치하는지 검증하고, 해시를 버전, cost, 솔트, 다이제스트로 분해해 보여 줍니다. 테스트 사용자를 시드할 때, 마이그레이션 중 데이터베이스의 해시가 알려진 비밀번호와 일치하는지 확인할 때, $2b$12$가 실제로 무슨 뜻인지 이해하고 싶을 때 유용합니다. 해싱은 Node.js, PHP, Python, Ruby, Go의 bcrypt 라이브러리와 호환되는 JavaScript 구현인 bcryptjs로 브라우저에서 실행됩니다. 테스트 계정 여러 개를 시드하려면 일괄 모드로 최대 50개의 비밀번호 목록을 한 번에 해시할 수 있습니다.

Bcrypt는 일부러 느리게 만들어졌고, cost가 1 올라갈 때마다 시간이 두 배가 됩니다. 이 도구는 작업 중 진행률을 보여 주고 다른 cost로는 이 기기에서 얼마나 걸릴지 추정해 주므로, 서버에 쓸 값을 고르기 전에 그 대가를 확인할 수 있습니다. 모든 온라인 도구에 해당하는 주의 사항이 하나 있습니다. 실제 운영 중인 비밀번호를 직접 관리하지 않는 웹 페이지에 붙여 넣지 마세요. 이 도구는 테스트 값과 해시 이해용으로 쓰세요.

사용 방법

비밀번호를 입력하고 cost를 고르세요. 로그인 시스템에서는 보통 10~12를 씁니다.
해시 생성을 누르세요. 실행되는 동안 진행률 표시줄이 나타나며, cost 14나 15에서는 몇 초가 걸릴 수 있습니다.
60자짜리 해시를 복사하세요. 솔트가 무작위이므로 다시 생성하면 다른 해시가 나오지만, 둘 다 검증에 통과합니다.
해시를 확인하려면 검증 영역에 해시와 확인할 비밀번호를 붙여 넣고 검증을 누르세요.
해시 구조 표에서 해시가 어떤 버전과 cost를 쓰는지 확인하세요.

자주 묻는 질문

여러 비밀번호를 한 번에 bcrypt 해시할 수 있나요?

네. "비밀번호 목록(일괄)"로 전환하고 한 줄에 하나씩 최대 50개의 비밀번호를 붙여 넣은 뒤(공백도 포함되며 빈 줄은 건너뜀) 해시를 누르세요. 고른 cost로 하나씩 순서대로, 각각 고유한 무작위 솔트로 해시하며, 작업하는 동안에도 페이지는 멈추지 않습니다. 목록과 같은 순서로 해시를 복사하거나, 평문 비밀번호를 포함하거나 빼고 CSV로 다운로드하세요. 제한을 둔 이유는 bcrypt가 일부러 느리기 때문입니다. cost 12로 50개를 해시하는 것만으로도 꽤 걸립니다.

bcrypt cost는 얼마로 해야 하나요?

운영 서버에서 해시 하나가 견딜 만한 지연(보통 100 ms~1초) 안에 끝나는 가장 높은 cost를 고르세요. 현재 서버 하드웨어에서는 대개 10~12입니다. OWASP의 Password Storage Cheat Sheet는 최소 작업 계수를 10으로 정하고 있습니다. 노트북이 아니라 실제 서버에서 측정하고, cost가 높으면 로그인 엔드포인트가 요청으로 과부하되기도 쉬워진다는 점을 기억하세요.

같은 비밀번호인데 bcrypt 해시가 매번 다른 이유는 무엇인가요?

해시마다 새로운 128비트 무작위 솔트가 들어가며, 이 솔트는 해시 자체(cost 뒤의 22자)에 저장됩니다. 의도된 동작입니다. 같은 비밀번호를 쓰는 두 사용자의 해시가 달라지고, 미리 계산된 테이블은 쓸모가 없어집니다. 비밀번호를 확인할 때 bcrypt는 저장된 해시에서 솔트와 cost를 읽어 후보 비밀번호를 다시 해시한 뒤 비교합니다.

bcrypt 해시를 복호화할 수 있나요?

아니요. Bcrypt는 암호화가 아니라 단방향 해시입니다. bcrypt 해시에서 비밀번호를 알아내는 유일한 방법은 후보를 추측해서 하나하나 해시해 보는 것이고, cost가 모든 추측을 비싸게 만듭니다. 그것이 목적입니다. 약한 비밀번호는 여전히 추측될 수 있지만, 시도 한 번에 나노초가 아니라 실제 CPU 시간이 듭니다.

$2a$, $2b$, $2y$의 차이는 무엇인가요?

알고리즘 구현의 개정판을 나타냅니다. $2a$는 오랫동안 쓰인 버전이고, $2b$는 255바이트가 넘는 비밀번호 처리를 고치기 위해 OpenBSD가 2014년에 도입했으며, $2y$는 PHP가 2011년 부호 확장 버그를 고친 뒤 만든 해시를 나타내는 표시입니다. 현재 라이브러리로 만든 해시라면 검증 방식은 같고, 대부분의 라이브러리가 세 가지를 모두 받습니다.

bcrypt에 비밀번호 최대 길이가 있나요?

네. Bcrypt는 비밀번호의 처음 72바이트만 쓰고 나머지는 무시합니다. UTF-8 바이트 기준이므로 악센트 문자나 이모지로 된 비밀번호는 더 적은 글자 수로 한도에 도달합니다. 이 도구는 72바이트를 넘으면 경고합니다. 더 긴 패스프레이즈를 받아야 한다면 길이를 제한하거나 이런 제한이 없는 Argon2id를 쓰세요.

bcrypt와 Argon2 중 무엇을 써야 하나요?

새 시스템이라면 OWASP는 Argon2id를 우선 권장합니다. 메모리 하드 방식이라 GPU로 공격하기가 더 비싸기 때문입니다. Bcrypt도 어디서나 지원되는 건전한 선택이며, 이미 cost 10 이상으로 bcrypt를 쓰는 시스템이라면 급히 바꿀 필요는 없습니다. 가장 중요한 것은 단순 SHA-256이나 MD5가 아니라 이런 느리고 솔트를 쓰는 알고리즘 중 하나를 쓰는 것입니다.

bcrypt 해시의 구조

$2b$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquzi.Ss7KIUgO2t0jWMUW 같은 bcrypt 해시는 항상 60자이며, 검증에 필요한 모든 정보를 담고 있습니다.

• $2b$: 알고리즘 버전.

• 12$: cost. 키 설정이 2^12 = 4,096번 실행됩니다.

• R9h/cIPz0gi.URNNX3kh2O: 128비트 무작위 솔트를 인코딩한 22자.

• PST9/PgBkqquzi.Ss7KIUgO2t0jWMUW: 결과 중 184비트를 인코딩한 31자.

인코딩에는 표준 Base64 알파벳이 아닌 bcrypt 고유의 Base64 알파벳(./A–Z a–z 0–9)을 쓰므로, 일반 Base64 디코더로는 각 부분을 해독할 수 없습니다.

빠른 해시가 비밀번호에 맞지 않는 이유

SHA-256 같은 범용 해시는 빠르도록 설계되었고, 최신 GPU는 초당 수십억 개를 계산합니다. SHA-256 비밀번호 해시 데이터베이스가 유출되면 흔한 비밀번호와 짧은 비밀번호 대부분이 몇 시간 안에 뚫립니다. 솔트를 추가하면 미리 계산된 테이블은 막을 수 있지만 추측 속도를 늦추지는 못합니다.

Bcrypt는 해시 하나하나를 일부러 비싸게, 그리고 조절 가능하게 만들어 이를 해결합니다. cost 12에서는 일반적인 서버 코어에서 해시 하나에 약 4분의 1초가 걸리며, 같은 코어에서 SHA-256 한 번보다 약 백만 배 오래 걸립니다. bcrypt의 메모리 접근 패턴은 GPU에서도 잘 돌아가지 않습니다. 하드웨어가 빨라지면 cost를 올리면 되고, 기존 해시는 각 사용자가 다음에 로그인할 때 업그레이드할 수 있습니다.

해싱은 한 겹의 방어일 뿐입니다. 로그인 시도 횟수를 제한하고, NIST SP 800-63B 권고대로 새 비밀번호를 유출된 비밀번호 목록과 대조하고, 2단계 인증을 제공해 추측한 비밀번호만으로는 로그인할 수 없게 하세요.