hmac-bcrypt

이 저장소에는 여러 언어로 작성된 hmac-bcrypt 비밀번호 해싱 함수의 레퍼런스 구현이 포함되어 있습니다. 각 레퍼런스 구현은 가능한 한 @epixoip이 만든 원본 C 및 Perl 구현의 1:1 포트를 목표로 하며, 서로 완전히 호환됩니다(즉, 동일한 해시 값을 생성하고 검증합니다.)

인터페이스

각 레퍼런스 구현은 다음과 같은 의사 프로토타입을 가진 두 개의 절차적 함수를 정의합니다:

string hmac_bcrypt_hash(password, settings?, pepper?)

boolean hmac_bcrypt_verify(password, expected, pepper?)

프로젝트에서 이러한 함수를 통합하고 사용하는 방법은 각 레퍼런스 구현과 함께 제공되는 테스트 케이스를 참조하십시오. 단순함을 위해 절차적 인터페이스가 선택되었지만, 원하는 대로 이러한 함수를 클래스나 객체에 통합해도 됩니다.

여기서 settings 매개변수는 표준 bcrypt 설정 문자열을 나타내며, 여기에는 해시 식별자(2a), log2 비용(예: 13), 그리고 선택적인 22바이트 radix64 인코딩 솔트 값(예: LhayLxezLhK1LhWvKxCyLO)이 포함됩니다. 이러한 값들은 달러 기호로 구분된 문자열로 함께 연결됩니다(예: $2a$13$LhayLxezLhK1LhWvKxCyLO).

settings 매개변수는 선택 사항입니다. 대부분의 경우 기본 비용인 13과 생성된 솔트를 사용하려면 null/빈 값으로 두어야 합니다. 기껏해야 13 이외의 비용 값을 사용하려면 ID + 비용 값만 제공할 수 있습니다(예: $2a$10$). 자신만의 솔트 값을 생성하여 제공하는 것은 권장되지 않습니다!

pepper 매개변수는 전역 공유 비밀을 정의하며 마찬가지로 선택 사항입니다. null/빈 값이면 hmac_bcrypt의 기본값이 사용됩니다. 이는 주로 슈킹 방어를 위한 것이지만, 크래킹의 보안성, 난이도, 비용을 높이는 데에도 사용할 수 있습니다(특히 HSM과 함께 사용할 때).

알고리즘 세부 사항

hmac-bcrypt 비밀번호 해싱 함수는 적절한 사전 해싱과 사후 해싱과 함께 bcrypt를 사용하며, 선택적 pepper와 결합됩니다. 의사 코드로 표현하면 매우 간단합니다:

pre_hash  = hmac_sha512_base64(password, pepper)
mid_hash  = bcrypt(pre_hash, settings)
post_hash = hmac_sha512_base64(mid_hash, pepper)

return settings + post_hash

사전 해싱은 bcrypt의 최대 입력 크기인 72바이트를 초과하는 입력 길이를 허용하기 위해 사용됩니다. SHA-512는 64비트 워드 크기로 인해 선택되었으며, 이는 CPU 방어자에게 유리하지만 GPU 공격자를 방해합니다. 그러나 원시 SHA-512 값을 사용할 수 없는 데에는 여러 가지 이유가 있습니다:

1. bcrypt에 입력되는 솔트되지 않은 원시 해시 값은 슈킹 공격을 가능하게 할 수 있습니다.
2. 일부 bcrypt 구현은 입력을 null로 종료되는 cstring으로 처리하므로, null 바이트를 포함하는 해시 값의 입력이 잘릴 수 있습니다.
3. 일부 bcrypt 구현은 입력을 signed char로 처리하고 각 바이트의 하위 7비트만 사용하므로 이진 입력에는 적합하지 않습니다.

슈킹 공격을 완화하려면 사전 해시는 솔트 처리되어야 합니다 -- 즉, 이 경우에는 pepper 처리 -- HMAC는 해시에 키를 적용하는 편리한 수단을 제공합니다. 그런 다음 결과 HMAC 값은 base64로 인코딩되어 null 바이트 및 이진 데이터 관련 문제를 완화하는 깨끗한 하위 ASCII 입력을 생성합니다.

예리한 독자라면 hmac_sha512_base64가 88바이트의 데이터를 생성하는 반면 bcrypt의 최대 입력 크기는 72바이트라는 점을 알아차릴 것입니다. 이는 문제가 되지 않으며, 실제로 sha256과 같이 더 적은 입력 데이터를 생성하는 해시 알고리즘을 사용하는 것보다 선호됩니다. 72바이트를 모두 채우고자 하며, sha512를 432비트로 잘라도 보안이 손실되지 않습니다(이는 sha384가 제공하는 384비트보다 큽니다.)

사후 해싱은 주로 hmac-bcrypt 해시를 bcrypt 해시와 구별하기 위해 사용됩니다 -- 즉, 길이가 달라집니다 -- 또한 pepper로 인한 추가 보호 계층을 제공하기 위해서도 사용됩니다. 사후 해싱 단계는 추가 보호를 위해 pepper 값을 HSM에 저장하여 수행할 수도 있습니다(매우 권장됨!).

정당성

메모리 하드니스는 흥미로운 실험이었지만, 가속에 대한 저항을 달성하는 올바른 경로는 분명히 캐시 하드니스입니다. 메모리 속도와 대역폭은 계속 증가하는 반면, RAM은 더 커지고, 저렴해지며, 더 조밀해지고 있습니다. 그러나 캐시 크기, 캐시 속도, 캐시 비용은 상대적으로 정적입니다. 하드웨어 scatter/gather 명령어조차 캐시 하드 알고리즘에 대해 한때 예측했던 것만큼 극적인 영향을 미치지 못했습니다.

가장 우수한 메모리 하드 알고리즘인 Argon2와 scrypt는 실제로 대상 런타임이 1000ms 미만인 경우 캐시 하드 알고리즘보다 가속에 대한 저항이 낮아 훌륭한 KDF이지만 실시간 인증에는 적합하지 않습니다.

이상적으로는 pufferfish나 bscrypt와 같은 의도적으로 캐시 하드한 비밀번호 해싱 함수를 사용해야 합니다. 그러나 이러한 함수는 더 새롭고, 연구가 덜 되었으며, 사용 가능한 라이브러리가 거의 없습니다. 반면 bcrypt는 의도치 않게 캐시 하드하지만 사실상 모든 언어와 프레임워크에서 쉽게 사용할 수 있습니다. 우리가 쉽게 사용할 수 있는 알고리즘 중에서 bcrypt는 실시간 대화형 인증(대상 런타임 < 1000ms)에 대해 가장 강한 가속 저항을 제공하므로, 명백한 답은 사용 가능한 bcrypt를 활용하는 것입니다.

그러나 bcrypt에는 몇 가지 주목할 만한 한계가 있으며, 목소리 높은 비판자들이 재빨리 지적하듯이:

1. 최대 입력이 72바이트로 제한됩니다(일부 구현에서는 그 이하)
2. 일부 구현은 손상되어 있습니다

hmac-bcrypt는 이러한 두 가지 문제와 그 이상을 해결합니다.