[security] 해시를 위해 소금을 숨길 필요성

직장에서 우리는 소금에 대한 두 가지 경쟁 이론을 가지고 있습니다. 내가 작업하는 제품은 사용자 이름이나 전화 번호와 같은 것을 사용하여 해시를 솔트합니다. 본질적으로 각 사용자마다 다르지만 우리가 쉽게 사용할 수있는 것입니다. 다른 제품은 각 사용자에 대해 무작위로 솔트를 생성하고 사용자가 암호를 변경할 때마다 변경합니다. 그런 다음 솔트는 데이터베이스에서 암호화됩니다.

내 질문은 두 번째 접근 방식이 정말로 필요한지 여부입니다. 순전히 이론적 관점에서 첫 번째 접근 방식보다 더 안전하다는 것을 이해할 수 있지만 실용성 관점에서는 어떨까요? 현재 사용자를 인증하려면 솔트가 암호화되지 않고 로그인 정보에 적용되어야합니다.

그것에 대해 생각한 후, 나는이 접근 방식에서 진정한 보안 이득을 보지 못했습니다. 계정에서 계정으로 솔트를 변경하면 공격자가 각 계정에 대한 것이 무엇인지 신속하게 파악하는 방법을 알고 있더라도 누군가가 해싱 알고리즘을 무차별 대입하려고 시도하는 것은 매우 어렵습니다. 이것은 암호가 충분히 강력하다는 가정하에 진행됩니다. (분명히 두 자리 숫자 인 비밀번호 세트에 대해 올바른 해시를 찾는 것이 8 자리 비밀번호의 올바른 해시를 찾는 것보다 훨씬 쉽습니다). 내 논리가 잘못되었거나 내가 놓친 것이 있습니까?

편집 : 좋아 그래서 여기에 내가 소금을 암호화하는 것이 정말로 논쟁이라고 생각하는 이유가 있습니다. (내가 올바른 길을 가고 있는지 알 수 있음).

다음 설명에서는 암호가 항상 8 자이고 솔트가 5이고 모든 암호가 소문자로 구성되어 있다고 가정합니다 (수학이 더 쉬워 짐).

각 항목에 대해 다른 소금을 사용한다는 것은 동일한 무지개 테이블을 사용할 수 없음을 의미합니다 (실제로는 충분한 크기의 테이블이 있으면 사용할 수 있지만 지금은 무시하겠습니다). 이것이 내가 이해하는 소금의 진정한 열쇠입니다. 왜냐하면 모든 계정을 깨뜨리기 위해서는 각각에 대해 말할 수 있도록 바퀴를 재발 명해야하기 때문입니다. 이제 해시를 생성하기 위해 올바른 솔트를 암호에 적용하는 방법을 안다면 솔트가 실제로 해시 된 구문의 길이 / 복잡성을 확장하기 때문에 그렇게 할 것입니다. 그래서 나는 내가 소금이 무엇인지 알고 있기 때문에 암호 + 소금을 13 ^ 26에서 8 ^ 26으로 “알기”위해 생성해야 할 가능한 조합의 수를 줄일 것입니다. 이제는 더 쉬워 지지만 여전히 정말 어렵습니다.

그래서 소금을 암호화합니다. 솔트가 암호화되어 있다는 것을 안다면 먼저 암호화를 시도하거나 해독하지 않을 것입니다 (충분한 수준의 암호화가 있다고 가정 할 때). 나는 그것을 무시할 것이다. 암호를 해독하는 방법을 알아내는 대신 이전 예제로 돌아가서 13 ^ 26에 대한 모든 키를 포함하는 더 큰 무지개 테이블을 생성합니다. 소금을 모르면 확실히 속도가 느려지지만 소금 암호화를 먼저 해독하려는 기념비적 인 작업을 추가하지는 않을 것입니다. 그럴 가치가 없다고 생각하는 이유입니다. 생각?

다음은 무차별 대입 공격시 암호가 얼마나 오래 유지되는지 설명하는 링크입니다.
http://www.lockdown.co.uk/?pg=combi

답변

UserId  UserName,   Password
     1  Fred       Hash1 =  Sha(Salt1+Password1)
     2  Ted        Hash2 =  Sha(Salt2+Password2)