사용자 비밀번호 솔트의 최적 길이는 얼마입니까? [닫은]

모든 소금 은 사용자의 암호를 소금에 절이고 해시 할 때 분명히 도움이됩니다. 소금이 얼마나 오래 지속되어야하는지에 대한 모범 사례가 있습니까? 사용자 테이블에 솔트를 저장하므로 스토리지 크기와 보안 사이의 최상의 균형을 원합니다. 임의의 10 문자 소금이면 충분합니까? 아니면 더 긴 것이 필요합니까?

이러한 답변의 대부분은 약간 잘못 안내되어 소금과 암호화 키 사이의 혼란을 보여줍니다. 솔트를 포함하는 목적은 저장된 각 비밀번호 해시가 개별적으로 공격되도록 각 사용자의 비밀번호를 해시하는 데 사용되는 기능을 수정하는 것입니다. 유일한 보안 요구 사항은 사용자마다 고유해야하며 예측할 수 없거나 추측하기 어려운 이점이 없습니다.

소금은 각 사용자의 소금이 독특 할 정도로 길어야합니다. 임의의 64 비트 솔트는 10 억 명의 등록 된 사용자라도 반복 될 가능성이 거의 없으므로 괜찮습니다. 단일 반복 솔트는 비교적 작은 보안 문제이므로 공격자가 두 계정을 한 번에 검색 할 수 있지만 전체 데이터베이스에서 검색 속도를 크게 향상 시키지는 않습니다. 32 비트 솔트조차도 대부분의 경우 허용되지만 최악의 경우 공격자의 검색 속도가 약 58 % 빨라집니다. 64 비트 이상으로 염분을 증가시키는 비용은 높지 않지만 그렇게 할 보안 이유는 없습니다.

사용자 별 솔트 위에 사이트 전체 솔트를 사용하면 다른 이점이 있습니다. 이렇게하면 다른 사이트에 저장된 비밀번호 해시와의 충돌을 막을 수 있고 32 비트의 비트조차도 일반 레인보우 테이블을 사용할 수 없습니다 소금은 무지개 테이블을 비현실적인 공격으로 만들기에 충분합니다.

더 단순하고 개발자조차도 항상 이것을 간과합니다. 고유 한 사용자 ID 또는 로그인 이름이 있으면 소금으로 완벽하게 작동합니다. 이 작업을 수행하는 경우 동일한 아이디어를 가진 다른 시스템 사용자와 겹치지 않도록 사이트 전체 소금을 추가해야합니다.

현재 해싱 암호에 대해 허용되는 표준 은 모든 암호에 대해 새로운 16 자 길이의 새 소금을 만들고 암호 해시와 함께 소금을 저장합니다.

물론 무작위로 소금을 만들려면 적절한 암호 관리가 필요합니다.

편집 : 내 아래 답변은 요청에 따라 질문에 대답하지만 "실제"답변은 bcrypt , scrypt 또는 Argon2 만 사용 하십시오 . 이와 같은 질문을한다면 너무 낮은 수준의 도구를 사용하는 것입니다.

솔직히 말해서 소금이 해시 암호와 동일한 길이를 갖지 않아야하는 확실한 이유는 없습니다. SHA-256을 사용하는 경우 256 비트 해시가 있습니다. 256 비트 솔트를 사용하지 않는 이유는 없습니다.

256 비트 이상은 수학적으로 보안을 향상시키지 않습니다. 그러나 더 짧은 소금을 섭취하면 무지개 테이블이 소금 길이를 따라 잡는 상황, 특히 소금이 짧은 경우가 있습니다.

위키 백과 :

Linux, BSD Unixes 및 Solaris에서 사용되는 SHA2-crypt 및 bcrypt 메소드에는 128 비트의 소금이 있습니다. 이러한 더 큰 솔트 값은 가까운 시일 내에 이러한 시스템에 대해 거의 모든 길이의 암호에 대한 사전 계산 공격을 불가능하게합니다.

128 비트 (16 바이트) 솔트이면 충분합니다. 128 / 4 = 3216 진수 로 표시 할 수 있습니다 .

하나의 해답은 사용하려는 해시가 보안 측면에서 제공하는 가치를 소금의 크기로 사용하는 것입니다.

예를 들어 SHA-512를 사용하려는 경우 SHA-512에서 제공하는 보안이 256 비트이므로 256 비트 솔트를 사용하십시오.