해시/암호화
Bcrypt Hash + Verify
bcrypt로 비밀번호를 해시화하고(랜덤 솔트와 조정 가능한 비용) 기존 bcrypt 해시와 비밀번호를 대조 검증합니다.
Bcrypt is a deliberately slow password-hashing algorithm: unlike MD5 or SHA-256, it intentionally requires heavy computation so that brute-forcing passwords stays impractical even if a database of hashes leaks.
How to use it
- Hash: enter a password and set a cost factor — a higher number means slower, more secure hashing.
- Every hash call generates a fresh random salt, so the same password produces a different hash each time — that's expected and normal.
- Verify: paste a password and an existing bcrypt hash to check whether they match, without hashing manually yourself.
Common uses
- Manually checking that a backend hashes passwords correctly before storing them.
- Generating a test bcrypt hash for seed data or fixtures during development.
- Debugging a failed login by comparing an entered password against the stored hash.
Things to keep in mind
Pick a cost factor that keeps hashing around 100-300ms on your target server — a balance between security and login-time load.
Bcrypt truncates passwords longer than 72 bytes — characters beyond that limit are ignored by the algorithm.
자주 묻는 질문
솔트를 직접 관리해야 하나요?
아니요. bcrypt는 해시화할 때마다 랜덤 솔트를 자동으로 생성해 해시 문자열 안에 포함시키므로 별도로 솔트를 저장하거나 관리할 필요가 없습니다.
비밀번호가 아주 길어도 안전한가요?
bcrypt는 72바이트를 넘는 부분을 조용히 잘라냅니다. 즉 72바이트 이후의 문자는 해시 결과에 아무런 영향을 주지 않으니, 매우 긴 비밀번호를 사용할 때는 이 점을 염두에 두세요.
비용(cost) 값은 어떻게 정해야 하나요?
비용은 값이 1 증가할 때마다 계산 시간이 두 배가 되는 지수적 관계입니다. 값이 클수록 무차별 대입 공격에 강해지지만 해시 계산도 느려지므로, 서버 하드웨어 성능에 맞춰 적절한 값을 선택해야 합니다.
bcrypt에는 비밀번호 길이 제한이 있나요?
네, bcrypt는 비밀번호의 처음 72바이트만 처리하며 그보다 긴 부분은 경고 없이 버려집니다. 실제로는 문제가 되는 경우가 드물지만, 매우 긴 비밀번호나 한 글자가 여러 바이트를 차지하는 비-ASCII 문자를 다룰 때는 이 점을 기억해야 합니다.
Argon2가 있는데도 bcrypt를 여전히 권장하는 이유는 무엇인가요?
bcrypt는 수십 년간 실전에서 검증되었고 거의 모든 언어와 프레임워크에서 널리 지원되며 여전히 충분히 안전한 선택입니다. Argon2는 GPU/ASIC 공격에 대한 방어력 때문에 새 시스템에서 우선적으로 권장되지만, bcrypt가 위험하다는 뜻은 아니며 단지 전용 하드웨어에 대한 저항력이 상대적으로 낮을 뿐입니다.