cost factor 는 몇이 적절한가요?

2026년 기준 12 이상 권장. 일반 서버에서 hash 1회에 ~250ms. 모바일은 10도 OK. cost 가 1 올라갈 때마다 시간 2배.

왜 SHA-256 대신 bcrypt 인가요?

SHA 는 너무 빠릅니다 — GPU 로 초당 수십억 hash 계산 가능. bcrypt 는 의도적으로 느리게(cost factor) 설계됐고 매 hash 마다 새 salt 가 자동 생성됩니다.

맞습니다 — 2015년 Password Hashing Competition 우승. memory-hard 라 GPU 공격에도 강함. 새 프로젝트라면 argon2id 권장. 다만 bcrypt 는 거의 모든 언어·DB 에 라이브러리가 있어 호환성↑.

예시

비밀번호: password
cost(rounds): 10

$2b$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy

$2b$ 는 알고리즘 버전, 10 은 cost factor(2^10 = 1024 round). hash 자체에 salt + cost 가 포함돼 있어 검증 시 별도 저장 불필요.

사용법 / 자주 묻는 질문

Q.cost factor 는 몇이 적절한가요?: A.2026년 기준 12 이상 권장. 일반 서버에서 hash 1회에 ~250ms. 모바일은 10도 OK. cost 가 1 올라갈 때마다 시간 2배.
Q.왜 SHA-256 대신 bcrypt 인가요?: A.SHA 는 너무 빠릅니다 — GPU 로 초당 수십억 hash 계산 가능. bcrypt 는 의도적으로 느리게(cost factor) 설계됐고 매 hash 마다 새 salt 가 자동 생성됩니다.
Q.argon2 가 더 좋다고 들었는데?: A.맞습니다 — 2015년 Password Hashing Competition 우승. memory-hard 라 GPU 공격에도 강함. 새 프로젝트라면 argon2id 권장. 다만 bcrypt 는 거의 모든 언어·DB 에 라이브러리가 있어 호환성↑.

재미있는 사실

bcrypt 는 1999년 USENIX 에서 Niels Provos 와 David Mazières 가 발표한 'A Future-Adaptable Password Scheme' 논문이 출발입니다. '하드웨어가 빨라져도 work factor 만 올리면 살아남는다' 는 핵심 아이디어가 25년이 지난 지금도 그대로 통합니다.
USENIX 1999 — Provos & Mazières
bcrypt 는 Blowfish 의 변형인 'eksblowfish' 를 씁니다 — Expensive Key Setup. 일반 Blowfish 의 키 setup 을 일부러 느리게 만들어, GPU 가 빠른 ALU 가 아니라 4 KB cache 와 메모리 latency 에 발목을 잡히도록 설계됐어요. 이게 SHA 계열보다 GPU/ASIC 공격에 강한 이유입니다.
Wikipedia — bcrypt
해시 앞 prefix `$2a$` `$2b$` `$2y$` 는 모두 같은 알고리즘이지만 버전이 달라요. 2011년 PHP 의 bcrypt 구현에서 8-bit char sign-extension 버그가 발견돼 `$2x$`/`$2y$` 분기가 생겼고, 이후 OpenBSD 도 `$2a$` → `$2b$` 로 옮겼습니다. 라이브러리는 verify 시 모든 prefix 를 받아들입니다.
Openwall — bcrypt sign-extension bug