Bcrypt 생성기

Bcrypt 생성기는 어떤 문자열이든 안전한 비밀번호 저장에 사용할 수 있는 bcrypt 비밀번호 해시로 만들어 주는 무료 도구입니다.

bcrypt란 무엇이며, 지금도 안전한가요?

Bcrypt는 적절한 비용 값을 설정하면 지금도 비밀번호 저장에 사용할 수 있는 해싱 알고리즘입니다. 다만 최신 시스템에서는 Argon2id를 선호하는 경우가 많습니다. Niels Provos와 David Mazières는 각 비밀번호 추측에 의도적으로 많은 연산이 필요하도록 Blowfish 암호의 키 스케줄링 과정을 이용해 1999년에 bcrypt를 설계했습니다.

해싱은 단방향 처리입니다. 따라서 애플리케이션은 원래 비밀번호를 복원하는 대신, 저장된 매개변수로 입력된 비밀번호를 해싱해 일치 여부를 확인합니다. SHA-3 같은 범용 알고리즘과 달리 bcrypt는 버전, 비용, 솔트, 체크섬이 모두 포함된 고정 길이의 독립적인 인코딩 레코드를 생성합니다.

표준 bcrypt 레코드의 길이는 ASCII 문자 60개입니다. 체크섬은 184비트를 나타내며, bcrypt 고유의 Base64 계열 인코딩에서는 31자로 표시됩니다. Bcrypt는 암호학적으로 깨진 알고리즘으로 간주되지는 않지만, 오래된 설계에서 비롯된 한계가 있습니다. 기존 구현은 입력을 최대 72바이트까지만 처리합니다. 또한 Argon2id는 bcrypt에 없는 메모리 경성 보호 기능을 제공합니다.

Bcrypt 생성기는 어떻게 사용하나요?

해싱할 문자열을 입력하고 생성기를 실행한 다음, Bcrypt 해시 결과 필드에 표시된 값을 복사하세요. 마지막 체크섬만 추출하지 말고 전체 결과를 저장해야 합니다.

1. 대소문자, 공백, 문장 부호까지 포함해 실제 비밀번호나 테스트 문자열을 정확히 입력하세요.
2. bcrypt 결과를 생성하세요.
3. 맨 앞의 버전 표시와 비용 값을 포함해 60자 전체를 복사하세요.
4. 데이터베이스의 비밀번호 해시 열에 결과를 저장하세요.
5. 로그인할 때는 새 해시를 생성해 텍스트를 직접 비교하지 말고, 플랫폼에서 제공하는 bcrypt 검증 함수를 사용하세요.

Bcrypt는 일반적으로 해시를 만들 때마다 새로운 무작위 솔트를 사용합니다. 따라서 같은 입력을 두 번 해싱해도 서로 다른 레코드가 생성될 수 있으며, 두 레코드 모두 해당 입력을 정상적으로 검증합니다. 이는 정상적인 동작이며, 같은 비밀번호가 동일한 저장 값으로 나타나는 것을 방지합니다.

작업은 서버에서 처리됩니다. 입력값은 HTTPS를 통해 서버로 전송되며 저장되지 않습니다. 실제 운영 환경의 비밀번호를 입력하려면 타사 온라인 서비스에 비밀번호를 입력하는 것이 조직의 보안 정책에 부합하는지 먼저 확인하세요.

bcrypt 해시를 복호화하거나 되돌릴 수 있나요?

아니요. bcrypt 해시는 암호화된 데이터가 아니며 복호화 키도 포함하지 않으므로 복호화할 수 없습니다. 현실적인 공격 방법은 가능한 비밀번호를 추측한 뒤, 각 추측값을 저장된 해시와 대조해 검증하는 것입니다.

Bcrypt는 설정 가능한 비용 값으로 이러한 추측 과정을 느리게 만듭니다. 하지만 짧거나 흔한 비밀번호, 이전에 유출된 비밀번호까지 안전하게 만들어 주지는 않으며, 공격자가 충분히 시도하면 취약한 입력을 찾아낼 수도 있습니다. 솔트는 여러 계정에 하나의 사전 계산 테이블을 재사용하는 공격을 막지만, 비밀 값은 아니며 저장된 레코드에 포함됩니다.

bcrypt 결과 읽는 방법

bcrypt 결과는 일반적으로 모듈러 crypt 형식을 따릅니다. 대표적인 구조는 $2y$12$[22-character salt][31-character checksum]입니다. 이는 특정 비밀번호의 해시가 아니라 형식을 설명하기 위한 예시입니다.

이 부분들은 항상 하나의 값으로 함께 보관하세요. 문자를 하나라도 바꾸거나 값을 잘라내거나 너무 짧은 열에 저장하면 일반적으로 검증에 실패합니다. 호환되는 라이브러리 사이에서도 버전 표시가 다를 수 있으므로, 애플리케이션이 레코드를 직접 분석해 다시 구성하기보다는 검증된 비밀번호 API를 사용해야 합니다.

bcrypt는 언제 사용해야 하나요?

Bcrypt는 이미 bcrypt를 지원하는 시스템에서 비밀번호를 해싱할 때 사용해야 합니다. 특히 기존 데이터베이스나 프레임워크와의 호환성이 중요할 때 적합합니다. 의도적으로 처리 속도가 느리고 솔트를 사용하므로, 일반적인 파일 체크섬이나 중복 제거 식별자로는 적합하지 않습니다.

• 적합한 용도에는 애플리케이션 비밀번호, 마이그레이션 테스트, 데이터베이스 필드 크기 확인, bcrypt 호환 개발 환경 재현이 포함됩니다.
• 대신 Argon2id를 사용해야 하는 경우는 플랫폼이 Argon2id를 지원하고 메모리 설정을 적절히 관리할 수 있는 새로운 비밀번호 시스템을 구축할 때입니다.
• 대신 SHA-3를 사용해야 하는 경우는 파일 무결성 확인, 콘텐츠 지문 생성, 중복 제거입니다. SHA-3/384 생성기와 SHA-3/512 생성기는 비밀번호 레코드가 아닌 범용 다이제스트를 생성합니다.
• bcrypt를 사용하면 안 되는 용도는 디지털 서명, 메시지 인증, 암호화, 나중에 복원해야 하는 데이터 저장입니다.

공백, 문장 부호, 숫자도 무시되지 않고 입력 데이터로 처리됩니다. 악센트가 있는 문자와 비라틴 문자는 bcrypt 처리 전에 바이트로 인코딩되므로, 두 시스템에서 동일한 문자 인코딩과 유니코드 정규화를 사용해 완전히 같은 바이트를 생성해야 합니다. 유니코드 문자 하나가 여러 바이트를 차지할 수 있으므로 72바이트 제한은 특히 중요합니다. 기술적으로는 빈 입력도 해싱할 수 있지만, 빈 비밀번호는 추측 공격에 대한 의미 있는 저항력을 제공하지 않습니다.

자주 묻는 질문

bcrypt 해시를 저장하려면 데이터베이스 공간이 얼마나 필요한가요?

일반적인 bcrypt 레코드에는 ASCII 문자 60개 이상을 저장할 수 있는 공간이 필요합니다. 향후 비밀번호 알고리즘을 변경할 가능성에 대비해 조금 더 넓은 필드를 사용해도 좋지만, 표준 인코딩 형식에는 바이너리 열이 필요하지 않습니다.

기존 SHA 비밀번호 해시를 bcrypt로 바꿀 수 있나요?

원래 비밀번호를 모르면 기존 SHA 다이제스트를 해당 비밀번호의 bcrypt 해시로 변환할 수 없습니다. 일반적으로 사용자가 다음에 로그인할 때 기존 해시를 검증한 뒤, 입력된 비밀번호를 bcrypt 또는 Argon2id로 해싱하고 이전 레코드를 교체하는 방식으로 마이그레이션합니다.

결과를 저장하기 전에 60자 전체를 빠짐없이 복사했는지, 데이터베이스 필드가 값을 잘라내지 않는지, 값을 받는 애플리케이션이 레코드의 버전 표시를 지원하는지 확인하세요.