비밀번호 해시 용 비 랜덤 솔트

업데이트 : 나는 최근 이 질문 에서 아래의 전체 토론에서 나 (그리고 다른 사람들도 그렇게했다고 확신합니다) 조금 혼란 스러웠다는 것을 알게되었습니다 . 내가 계속 무지개 테이블이라고 부르는 것은 실제로 해시 테이블이라고합니다. 무지개 테이블은 더 복잡한 생물이며 실제로 Hellman Hash Chains의 변형입니다. 대답은 여전히 ​​똑같다고 생각하지만 (암호 분석으로 내려 가지 않기 때문에) 일부 논의는 약간 왜곡 될 수 있습니다.
질문 : " 무지개 테이블은 무엇이며 어떻게 사용합니까? "

일반적으로 레인보우 테이블 공격으로부터 보호하기 위해 해시 기능 (예 : 암호)과 함께 사용하기 위해 항상 암호화 된 강력한 임의 값을 솔트로 사용하는 것이 좋습니다.

그러나 실제로 소금이 무작위로 암호로 필요합니까? 이와 관련하여 고유 한 값 (사용자 별 고유, 예 : userId)이면 충분합니까? 실제로 단일 Rainbow Table을 사용하여 시스템의 모든 (또는 대부분) 암호를 해독하는 것을 방지합니다.
하지만 엔트로피가 부족하면 해시 함수의 암호화 강도가 실제로 약화됩니까?

참고로 소금을 사용해야하는 이유, 보호하는 방법 (필요하지 않음), 단일 상수 해시 사용 (사용하지 않음) 또는 사용할 해시 함수의 종류에 대해 묻지 않습니다.
소금에 엔트로피가 필요한지 여부.

지금까지 답변 해 주신 모든 분들께 감사 드리지만, 제가 (조금) 덜 익숙한 영역에 집중하고 싶습니다. 주로 암호화 분석에 대한 의미-누군가 암호화 수학 PoV에서 입력 한 내용이 있다면 가장 감사하겠습니다.
또한 고려되지 않은 추가 벡터가있는 경우에도 훌륭한 입력입니다 (여러 시스템의 @Dave Sherohman 포인트 참조).
그 외에도 이론, 아이디어 또는 모범 사례가 있다면 증거, 공격 시나리오 또는 경험적 증거로이를 뒷받침하십시오. 또는 수용 가능한 트레이드 오프에 대한 유효한 고려 사항 ... 주제에 대한 모범 사례 (자본 B 자본 P)에 익숙합니다. 이것이 실제로 어떤 가치를 제공하는지 증명하고 싶습니다.

편집 : 여기에 정말 좋은 대답이 있지만 @Dave가 말했듯이 일반적인 사용자 이름에 대한 Rainbow Tables ... 그리고 가능한 덜 일반적인 이름도 있습니다. 하지만 내 사용자 이름이 전역 적으로 고유하면 어떻게됩니까? 내 시스템에 대해 반드시 고유 한 것은 아니지만 각 사용자마다 (예 : 이메일 주소).
단일 사용자를위한 RT를 구축 할 인센티브가 없으며 (@Dave가 강조했듯이 솔트는 비밀로 유지되지 않음) 여전히 클러스터링을 방지합니다. 유일한 문제는 내가 다른 사이트에서 동일한 이메일과 비밀번호를 가질 수 있다는 것입니다.하지만 소금은 어쨌든 그것을 막을 수 없습니다.
그래서 그것은 다시 암호화 분석으로 귀결됩니다-엔트로피가 필요합니까? (내 현재 생각은 암호 분석의 관점에서 필요하지 않지만 다른 실제적인 이유에서 나온 것입니다.)

솔트는 전통적으로 해시 된 암호의 접두사로 저장됩니다. 이것은 이미 암호 해시에 액세스 할 수있는 모든 공격자에게 알려지게합니다. 사용자 이름을 솔트로 사용하거나 사용하지 않아도 해당 지식에 영향을주지 않으므로 단일 시스템 보안에는 영향을 미치지 않습니다.

그러나 사용자 이름 또는 기타 사용자 제어 값을 salt로 사용하면 동일한 암호 해시 알고리즘을 사용하는 여러 시스템에서 동일한 사용자 이름과 암호를 가진 사용자가 동일한 암호 해시를 갖게되므로 시스템 간 보안이 저하됩니다. 각 시스템. 나는 공격자로서 계정을 손상시키는 다른 수단을 시도하기 전에 먼저 대상 계정이 다른 시스템에서 사용한 것으로 알려진 암호를 시도하기 때문에 이것이 중요한 책임이라고 생각하지 않습니다. 동일한 해시는 알려진 암호가 작동 할 것이라고 미리 알려주고 실제 공격을 더 쉽게 만들지는 않습니다. (하지만 계정 데이터베이스를 빠르게 비교하면 우선 순위가 더 높은 대상 목록을 제공 할 수 있습니다. 암호를 다시 사용하지 않는 사람이 누구인지 알려주기 때문입니다.)

이 아이디어의 더 큰 위험은 사용자 이름이 일반적으로 재사용된다는 것입니다. 방문하려는 모든 사이트에는 예를 들어 "Dave"라는 사용자 계정이 있고 "admin"또는 "root"가 훨씬 더 일반적입니다. 이러한 일반적인 이름을 가진 사용자를 대상으로하는 레인보우 테이블을 훨씬 쉽고 효과적으로 구성 할 수 있습니다.

이 두 가지 결함은 암호를 해싱하기 전에 두 번째 솔트 값 (고정되고 숨겨 지거나 표준 솔트처럼 노출됨)을 암호에 추가하여 효과적으로 해결할 수 있지만, 그 시점에서 대신 표준 엔트로피 솔트를 사용하는 것이 좋습니다. 사용자 이름을 작업하는 것입니다.

추가 편집 : 많은 사람들이 엔트로피와 소금의 엔트로피가 중요한지에 대해 이야기하고 있습니다. 그러나 그것에 대한 대부분의 의견이 생각하는 이유는 아닙니다.

일반적인 생각은 공격자가 소금을 추측하기 어렵도록 엔트로피가 중요하다는 것입니다. 이것은 부정확하고 사실 완전히 관련이 없습니다. 여러 사람들이 몇 번 지적했듯이 솔트의 영향을받는 공격은 암호 데이터베이스를 가진 사람 만 할 수 있고 암호 데이터베이스를 가진 사람은 각 계정의 솔트가 무엇인지 볼 수 있습니다. 추측 할 수 있는지 여부는 사소하게 검색 할 수있을 때 중요하지 않습니다.

엔트로피가 중요한 이유는 솔트 값의 클러스터링을 피하기 위해서입니다. 솔트가 사용자 이름을 기반으로하고 대부분의 시스템에 "root"또는 "admin"이라는 계정이 있다는 것을 알고 있다면이 두 솔트에 대한 레인보우 테이블을 만들 수 있으며 대부분의 시스템을 크랙합니다. 반면에 임의의 16 비트 솔트가 사용되고 임의 값이 대략 균등 한 분포를 갖는 경우 모든 2 ^ 16 가능한 솔트에 대해 무지개 테이블이 필요합니다.

공격자가 개인 계정의 소금이 무엇인지 알지 못하도록하는 것이 아니라 잠재적 인 표적의 상당 부분에 사용될 단일 소금의 크고 뚱뚱한 표적을주지 않는 것입니다.

높은 엔트로피 솔트를 사용하는 것은 암호를 안전하게 저장하는 데 절대적으로 필요합니다.

내 사용자 이름 'gs'를 내 비밀번호에 추가하십시오. 'MyPassword'는 gsMyPassword를 제공합니다. 사용자 이름에 엔트로피가 충분하지 않으면 특히 사용자 이름이 짧은 경우이 값이 이미 무지개 테이블에 저장되어있을 수 있기 때문에 레인보우 테이블을 사용하면 쉽게 깨집니다.

또 다른 문제는 사용자가 둘 이상의 서비스에 참여한다는 것을 알고있는 공격입니다. 많은 일반적인 사용자 이름이 있으며 아마도 가장 중요한 사용자 이름은 admin과 root입니다. 누군가가 가장 일반적인 사용자 이름으로 솔트를 사용하는 무지개 테이블을 만들면이를 사용하여 계정을 손상시킬 수 있습니다.

그들은 12 비트 솔트를 가지고 있었습니다. 12 비트는 4096 개의 서로 다른 조합입니다. 오늘날 많은 정보를 쉽게 저장할 수 있기 때문에 충분히 안전하지 않았습니다 . 가장 많이 사용되는 4096 개의 사용자 이름에도 동일하게 적용됩니다. 일부 사용자는 가장 일반적인 사용자 이름에 속하는 사용자 이름을 선택할 가능성이 있습니다.

암호 의 엔트로피를 해결하는 이 암호 검사기 를 찾았습니다 . 사용자 이름을 사용하는 것과 같이 암호에 엔트로피가 더 작 으면 레인보우 테이블이 최소한 엔트로피가 낮은 모든 암호를 덮으려고 할 때 훨씬 더 쉽게 발생할 수 있습니다.

사람들이 서로 다른 웹 사이트에서 사용자 이름을 공유 할 수 있기 때문에 사용자 이름만으로 문제가 될 수 있다는 것은 사실입니다. 그러나 사용자가 각 웹 사이트에서 다른 이름을 가지고 있다면 다소 문제가되지 않습니다. 따라서 각 웹 사이트에서 고유하게 만드는 것은 어떻습니까? 다음과 같이 비밀번호를 해시하십시오.

해시 함수 ( "www.yourpage.com/"+username+"/"+password)

이렇게하면 문제가 해결됩니다. 나는 암호화의 대가는 아니지만 높은 엔트로피를 사용하지 않는다는 사실이 해시를 더 약하게 만들 것이라고 확신합니다.

나는 두 가지를 모두 사용하는 것을 좋아한다 : 높은 엔트로피 랜덤 레코드 솔트와 레코드 자체의 고유 ID.

이것은 사전 공격 등에 대한 보안을 크게 강화하지 않지만 누군가가 자신의 암호를 자신의 것으로 바꾸려는 의도로 솔트와 해시를 다른 레코드에 복사하는 프린지 케이스를 제거합니다.

(당연히 이것이 적용되는 상황을 생각하기 어렵지만 보안과 관련하여 벨트와 브레이스에 해를 끼치 지 않는 것을 볼 수 있습니다.)

소금이 알려져 있거나 쉽게 추측 할 수 있다면 사전 공격의 난이도를 높이 지 않았습니다. "상수"소금을 고려하여 수정 된 무지개 테이블을 만드는 것도 가능할 수 있습니다.

고유 한 솔트를 사용하면 BULK 사전 공격의 어려움이 증가합니다.

고유하고 암호 학적으로 강력한 솔트 값을 갖는 것이 이상적입니다.

각 비밀번호마다 솔트가 다른 한 괜찮을 것입니다. 소금의 요점은 표준 무지개 테이블을 사용하여 데이터베이스의 모든 암호를 해결할 수 없다는 것입니다. 따라서 모든 암호에 다른 솔트를 적용하면 (임의가 아니더라도) 공격자는 기본적으로 각 암호에 대해 다른 솔트를 사용하기 때문에 각 암호에 대해 새로운 레인보우 테이블을 계산해야합니다.

더 많은 엔트로피가있는 솔트를 사용하는 것은이 경우 공격자가 이미 데이터베이스를 가지고 있다고 가정하기 때문에 많은 도움이되지 않습니다. 해시를 다시 만들 수 있어야하므로 솔트가 무엇인지 이미 알고 있어야합니다. 따라서 소금 또는 소금을 구성하는 값을 파일에 저장해야합니다. Linux와 같은 시스템에서는 솔트를 얻는 방법이 알려져 있으므로 비밀 솔트를 사용하는 데 소용이 없습니다. 해시 값을 가진 공격자가 아마도 당신의 솔트 값도 알고 있다고 가정해야합니다.

해시 함수의 강도는 입력에 의해 결정되지 않습니다!

공격자에게 알려진 솔트를 사용하면 레인보우 테이블 (특히 root 와 같은 하드 코딩 된 사용자 이름의 경우 )을 더 매력적으로 만들 수 있지만 해시를 약화 시키지는 않습니다 . 공격자에게 알려지지 않은 솔트를 사용하면 시스템을 공격하기가 더 어려워집니다.

사용자 이름과 암호의 연결은 여전히 ​​지능형 레인보우 테이블에 대한 항목을 제공 할 수 있으므로 해시 된 암호와 함께 저장된 일련의 의사 랜덤 문자 솔트를 사용하는 것이 좋습니다. 예를 들어 사용자 이름이 "potato"이고 암호가 "beer"인 경우 해시에 연결된 입력은 "potatobeer"이며 무지개 테이블에 대한 합리적인 항목입니다.

사용자가 비밀번호를 변경할 때마다 솔트를 변경하면 대소 문자 혼합, 구두점, 최소 길이, 이후 변경과 같은 합리적인 비밀번호 정책을 시행하는 것처럼 장기간의 공격을 방어하는 데 도움이 될 수 있습니다. n 주 .

그러나 다이제스트 알고리즘을 선택하는 것이 더 중요하다고 생각합니다. 예를 들어, SHA-512를 사용하는 것은 MD5보다 무지개 테이블을 생성하는 사람에게 더 많은 고통을 줄 것입니다.

솔트는 주어진 입력 값이 여러 번 해시되는 것을 보장하기 위해 가능한 한 많은 엔트로피를 가져야합니다. 결과 해시 값은 가능한 한 가깝고 항상 달라집니다.

솔트에서 가능한 한 많은 엔트로피로 끊임없이 변화하는 솔트 값을 사용하면 해싱 가능성 (예 : 암호 + 솔트)이 완전히 다른 해시 값을 생성 할 수 있습니다.

솔트의 엔트로피가 적을수록 동일한 솔트 값을 생성 할 가능성이 높아져서 동일한 해시 값을 생성 할 가능성이 높아집니다.

입력이 알려진 경우 해시 값이 "상수"이고 사전 공격 또는 레인보우 테이블이 매우 효과적 일 수있는 "상수"의 특성입니다. 가능한 한 많은 결과 해시 값을 변경함으로써 (높은 엔트로피 염 값을 사용하여) 동일한 입력 + 무작위 염을 해시하면 많은 다른 해시 값 결과가 생성되어 레인보우 테이블을 무효화 (또는 적어도 효과를 크게 감소)합니다. 공격.

엔트로피는 소금 값의 포인트입니다.

소금 뒤에 단순하고 재현 가능한 "수학"이 있다면 소금이없는 것과 같습니다. 시간 가치를 추가하는 것만으로도 괜찮습니다.