소금이 사전 공격을 '불가능'하게 만드는 이유는 무엇입니까?


85

업데이트 : 나는 소금이 무엇인지, 무지개 테이블이 무엇인지, 사전 공격이 무엇인지, 소금의 목적이 무엇인지 묻지 않습니다. 나는 질문하고 있습니다 : 사용자 솔트와 해시를 알고 있다면 암호를 계산하는 것이 쉽지 않습니까?

프로세스를 이해하고 일부 프로젝트에서 직접 구현합니다.

s =  random salt
storedPassword = sha1(password + s)

데이터베이스에 다음을 저장합니다.

username | hashed_password | salt

내가 본 모든 솔팅 구현은 비밀번호의 끝 또는 시작 부분에 솔트를 추가합니다.

hashed_Password = sha1(s + password )
hashed_Password = sha1(password + s)

따라서 소금 (ha ha)의 가치가있는 해커의 사전 공격은 위에 나열된 일반적인 조합으로 저장된 소금에 대해 각 키워드를 실행합니다.

확실히 위에서 설명한 구현은 근본적인 문제를 실제로 해결하지 않고 단순히 해커에게 또 다른 단계를 추가합니까? 이 문제를 해결할 수있는 대안이 있습니까? 아니면 문제를 오해하고 있습니까?

내가 생각할 수있는 유일한 일은 솔트와 비밀번호를 임의의 패턴으로 묶거나 해싱 프로세스에 다른 사용자 필드를 추가하는 비밀 블렌딩 알고리즘을 사용하는 것입니다. 즉, 해커가 데이터베이스에 액세스하고 코드를 묶어야한다는 의미입니다. 사전 공격을 통해 유익한 것으로 입증되었습니다. (댓글에서 지적했듯이 해커가 모든 정보에 액세스 할 수 있다고 가정하는 것이 가장 좋으므로 이것이 최선이 아닐 수 있습니다).

해커가 암호 및 해시 목록을 사용하여 사용자 데이터베이스를 해킹하는 방법에 대한 예를 들어 보겠습니다.

해킹 된 데이터베이스의 데이터 :

RawPassword (not stored)  |  Hashed   |     Salt
--------------------------------------------------------
letmein                       WEFLS...       WEFOJFOFO...

공통 암호 사전 :

   Common Password
   --------------
   letmein
   12345
   ...

각 사용자 레코드에 대해 공통 암호를 반복하고 해시합니다.

for each user in hacked_DB

    salt = users_salt
    hashed_pw = users_hashed_password

    for each common_password

        testhash = sha1(common_password + salt)
        if testhash = hashed_pw then
           //Match!  Users password = common_password
           //Lets visit the webpage and login now.
        end if

    next

next

이것이 내 요점을 훨씬 더 잘 보여주기를 바랍니다.

10,000 개의 공통 암호와 10,000 개의 사용자 레코드가 주어지면 가능한 많은 사용자 암호를 찾으려면 100,000,000 개의 해시를 계산해야합니다. 몇 시간이 걸릴 수 있지만 실제로는 문제가되지 않습니다.

크래킹 이론 업데이트

우리는 SHA1 해시와 솔트의 데이터베이스에 액세스 할 수있는 손상된 웹 호스트이며이를 혼합하는 알고리즘과 함께 있다고 가정합니다. 데이터베이스에는 10,000 개의 사용자 레코드가 있습니다.

이 사이트 는 GPU를 사용하여 초당 2,300,000,000 SHA1 해시를 계산할 수 있다고 주장합니다. (실제 상황에서는 아마도 더 느리 겠지만 지금은 인용 된 수치를 사용할 것입니다).

(((95 ^ 4) / 2300000000) / 2) * 10000 = 177 초

최대 길이가 4 자이고 계산 속도 (변수)로 나눈 값으로 나눈 95 개의 인쇄 가능한 ASCII 문자의 전체 범위가 10,000에 대해 2로 나눈 값 (암호 검색에 걸리는 평균 시간이 평균 순열의 50 %를 필요로한다고 가정) 사용자는 길이가 4 미만인 모든 사용자 암호를 계산하는 데 177 초가 걸립니다.

사실감을 위해 약간 조정 해 봅시다.

(((36 ^ 7) / 1000000000) / 2) * 10000 = 2 일

대소 문자를 구분하지 않고 암호 길이가 7 미만이고 영숫자 문자로만 가정하면 10,000 개의 사용자 레코드를 해결하는 데 4 일이 걸리며 오버 헤드와 비 이상적인 상황을 반영하기 위해 알고리즘 속도를 절반으로 줄였습니다.

이것은 선형적인 무차별 대입 공격이며 모든 계산은 서로 독립적이므로 여러 시스템에서 해결해야 할 완벽한 작업이라는 것을 인식하는 것이 중요합니다. (예외 시간의 절반이되는 서로 다른 끝에서 공격을 실행하는 2 대의 컴퓨터를 쉽게 설정할 수있는 IE).

이 작업을 계산적으로 더 비싸게 만들기 위해 암호를 1,000 번 재귀 적으로 해싱하는 경우를 고려합니다.

(((36 ^ 7) / 1000000000000) / 2) * 1000 초 = 10.8839117 시간

이는 한 명의 사용자에 대해 인용 된 숫자에서 절반 미만의 속도로 실행되는 최대 7 개의 영숫자 문자를 나타냅니다 .

재귀 적으로 1,000 회 해싱하면 포괄적 인 공격을 효과적으로 차단하지만 사용자 데이터에 대한 표적 공격은 여전히 ​​취약합니다.


12
솔팅의 요점은 해시 된 암호를 볼 수없고 여러 사용자가 동일한 해시 (따라서 동일한 암호)를 가지고 있음을 확인하는 것을 방지하는 것입니다. 솔팅 없이는 해싱 알고리즘을 사용하고 가능한 모든 해시를 생성 한 다음 해당 해시에 대한 무차별 검색을 수행 할 수 있습니다. 알고리즘은 절대 변경되지 않으므로 공격자가 예측할 수있게되므로 솔팅은 훨씬 더 어렵게 만듭니다.
BeRecursive

25
크래커는 민달팽이와 같고 소금은 피부의 점액을 건조시켜 죽이기 때문입니다.
TED

6
@TED ​​: 저는 소금에 절인 크래커를 좋아합니다. 소금에 절인 슬러그.
FrustratedWithFormsDesigner

3
@Tom-예제 공격에서. 솔트가없는 경우 공격자는 "각 공통 비밀번호에 대해 비밀번호를 해시합니다. 이것이 한 명 이상의 사용자와 일치합니까? 예, 비밀번호가 있습니다"를 수행 할 수 있습니다. 공격자는 모든 비밀번호를 "병렬로"공격 할 수 있습니다. , 추가 비용없이.
Damien_The_Unbeliever 2010-08-25

3
@Tom Gullen-사진의 절반 밖에 없습니다. 솔트가 없으면 공격자는 "업데이트 2"에서 설명한 방법을 사용하지 않습니다. 그는 단순히 테이블에서 조회를 수행하고 O (1) 또는 O (log n) 시간 (n은 후보 암호 수)에 암호를 가져옵니다. 소금 은 그것을 막고 그가 당신이 보여주는 O (n) 접근법을 사용하도록 강요하는 것입니다. 또 다른 기술 (키 강화)로 인해 루프의 각 시도에 1 초가 소요될 수 있습니다. 즉, 이러한 테스트를 수행하는 데 3 이 소요 됩니다. 시각.
erickson 2010-08-25

답변:


31

예, sha1 (salt | password)에 3 일만 있으면됩니다. 이것이 바로 좋은 암호 저장 알고리즘이 1000 회 반복 해싱을 사용하는 이유입니다. 8 년이 필요합니다.


3
+1, 가장 간결하고 지금까지 요점에 대한 대답은 이것이 옵션이라는 것을 몰랐습니다.
Tom Gullen

분명히 시스템에서 해시 벤치 마크를 수행 한 적이 없습니다. 초당 수백만 개의 sha1 계산을 수행 할 수 있습니다 . 1,000 라운드는 공격자에게 의미가 없습니다. 또한 sha1은 깨진 해시 함수이기 때문에 -1입니다.
루크

분명히 나는 ​​질문의 이름과 번호를 사용하고 있습니다. 화제와 명료 함 등을 들어 본 적이 있다면 ... 아, 루크 다. 신경 쓰지 마.
blaze

1
@Rook, 1,000 라운드는 무차별 대입에 1,000 배 더 오래 걸릴 것임을 의미합니다. 나에게 좋은 기능인 것 같습니다.
Tom Gullen 2011 년

공격자가 암호를 추측 할 수있는 경우,이 로그인에 대해 동일 (또는 뭔가 나에게 탈출 롤?)
khaled_webdev

62

사전 공격을 중지하지 않습니다.

그것이하는 일은 암호 파일의 복사본을 관리하는 누군가가 무지개 테이블 을 사용 하여 해시에서 암호가 무엇인지 알아내는 것을 막는 것입니다 .

하지만 결국에는 무차별 대입이 될 수 있습니다. 이 부분에 대한 대답은 사용자가 사전 단어를 암호로 사용하지 않도록하는 것입니다 (예 : 최소 하나의 숫자 또는 특수 문자 요구 사항).

업데이트 :

앞서 언급 했어야했지만 일부 (대부분?) 암호 시스템은 각 암호에 대해 다른 솔트를 사용하며 아마도 암호 자체와 함께 저장됩니다. 이것은 하나의 무지개 테이블을 쓸모 없게 만듭니다. 이것이 UNIX crypt 라이브러리가 작동하는 방식이며 최신 UNIX 유사 OS는 새로운 해시 알고리즘으로이 라이브러리를 확장했습니다.

SHA-256 및 SHA-512에 대한 지원이 최신 버전의 GNU crypt에 추가되었다는 사실을 알고 있습니다.


17
+1 Salt는 미리 계산 된 해시 목록 (레인보우 테이블)이 유용하지 않도록합니다. 공격자는 완전히 다시 시작해야합니다.
Ian Boyd

2
PHP에서는 md5 또는 sha1보다 더 나은 암호화를 위해 mcrypt 또는 bcrypt 라이브러리를 사용할 수 있습니다. md5 또는 sha1을 사용하는 경우 데이터베이스에 저장된 항목에 도달하기 전에 암호를 1000 번 해시하는 '확장'해야합니다. 이렇게하면 엔트로피가 동일하게 유지되지만 해시를 계산하는 시간이 늘어납니다.
Malfist 2010-08-25

2
@Tom Gullen, 어떤 기사를 읽고 있습니까? 자칭 전문가 또는 과학 저널의 피어 리뷰 기사?
Malfist

7
그리고 "보안"시스템을 작성하는 방법에 대한 블로그 / 도움말 게시물을 작성하는 것은 일반적인 Joe 개발자입니다. 보안은 측면에서 선택할 수있는 것이 아니라 광범위한 지식이 필요합니다. 불공평합니까? 아마. 안전 해요? 어느 정도. 보안 전문가가있는 데에는 이유가 있습니다. 그러나 다시 말하지만 모든 것이 Fort Knox만큼 안전 할 필요는 없습니다. 여기서 가장 좋은 정책은 해당 전문가가 설계 한 미리 구축 된 시스템을 사용하고 필요에 맞게 수정하는 것입니다.
Malfist

3
@Michael : 더 긴 솔트를 사용하면 가능한 모든 솔트 값을 미리 계산해야 레인보우 테이블에 표시됩니다. 요점은 모든 암호에 대해 동일한 솔트를 유지하지 않고 각 암호에 대해 무작위로 선택하여 저장된 해시 솔트 암호 옆에있는 데이터베이스에 저장한다는 것입니다. 따라서 해커는 가능한 각 값이 큰 솔트에 대해 레인보우 테이블에 항목이 필요하므로 테이블이 너무 커서 실행 가능하지 않게됩니다.
Colin DeClue

31

더 정확하게 말하면, 사전 공격 , 즉 완전한 목록의 모든 단어를 시도하는 공격은 "불가능"하지는 않지만 비실용적입니다 . 각 소금은 필요한 저장 및 계산 양을 두 배로 늘립니다 .

이것은 소금이 비밀인지 여부가 중요하지 않은 레인보우 테이블과 관련된 공격과 같은 사전 계산 된 사전 공격과 다릅니다.

예 : 64 비트 솔트 (예 : 8 바이트)를 사용하면 사전 공격에서 2 64 개의 추가 암호 조합 을 확인해야합니다 . 200,000 단어가 포함 된 사전을 사용하면

200,000 * 2 64 = 3.69 * 10 24

최악의 경우 테스트-소금없이 200,000 테스트 대신.

솔트 사용의 또 다른 이점은 공격자가 사전에서 암호 해시를 미리 계산할 수 없다는 것입니다. 너무 많은 시간 및 / 또는 공간이 필요합니다.

최신 정보

업데이트는 공격자가 이미 솔트를 알고 있거나 훔쳤다고 가정합니다. 물론 이것은 다른 상황입니다. 여전히 공격자가 미리 계산 된 레인보우 테이블을 사용하는 것은 불가능합니다. 여기서 중요한 것은 해싱 함수의 속도입니다. 공격을 비실용적으로 만들려면 해싱 기능이 느려 야합니다. MD5 또는 SHA는 빠르도록 설계 되었기 때문에 여기에서 좋은 후보가 아닙니다. 해싱 알고리즘에 대한 더 나은 후보는 Blowfish 또는 일부 변형입니다.

업데이트 2

일반적으로 암호 해시 보안 문제에 대한 좋은 읽기 (원래 질문을 훨씬 넘어서지 만 여전히 흥미 롭습니다) :

Rainbow Tables로 충분 : 보안 암호 체계에 대해 알아야 할 사항

기사의 결과 : bcrypt (Blowfish 기반) 또는 Eksblowfish로 만든 솔트 해시 를 사용하여 구성 가능한 설정 시간을 사용하여 해싱 속도를 늦출 수 있습니다.


4
@Tom Gullen-합리적인 강력한 암호 정책을 사용하더라도 수억 또는 수십억 명의 후보 사전은 모든 암호가 똑같지 않기 때문에 적중 될 가능성이 높습니다 (사람들이 RNG 대신 니모닉을 사용하여 선택하기 때문). . 그 크기의 사전 입니다 소금을 사용하지 않는 경우 상품 시스템 precomputable. 솔트를 사용하는 경우 공격자는 매번 해시를 다시 계산해야하며 충분한 해시 반복이 수행되면 공격자의 공격 속도가 초당 몇 번의 시도로 느려질 수 있습니다.
erickson 2010-08-25

3
-1 나에게서 : 비밀을 지키는 것은 소금의 요점이 아닙니다. 어쨌든 암호를 확인하기 위해 액세스 할 수 있어야하므로 암호를 비밀로 유지하려는 시도는 실제로 성공하기보다는 복잡성이 추가되어 시스템을 더 취약하게 만들 수 있습니다.
Michael Borgwardt

2
@ 0xA3 : 다시 : 공격자에게 알려지지 않은 것은 소금의 요점이 아닙니다 . 컴퓨터는 어떤 식 으로든 액세스해야하므로 컴퓨터에 침입 한 공격자도 액세스 할 수 있습니다. 공격자가 소금을 알지 못하는 시나리오는 붉은 청어입니다.
Michael Borgwardt

1
링크 된 기사가 레인보우 테이블을 잘못 설명하고 있다는 점을 언급 할 가치가 있다고 생각합니다. 그가 설명하는 것은 간단한 사전 첨부입니다. 레인보우 테이블은 정말 매우 다릅니다 (그리고 다소 더 복잡합니다). 레인보우 테이블이 실제로 어떻게 작동 하는지에 대한 꽤 괜찮은 설명이 있습니다 . kestas.kuliukas.com/RainbowTables
Jerry Coffin

3
-1 : "물론 소금은 비밀로 유지해야합니다." 공격자가 당신의 암호 해시에 접근 할 수 있다면, 그는 당신의 솔트도 가질 것입니다. 당신이 필요 로하는 것은 "숨겨진"솔트의 모호함을 통한 보안이 아니라 사용자 단위 솔트입니다.
snemarch aug

17

사전은 값이 키로 인덱싱되는 구조입니다. 사전 계산 된 사전 공격의 경우 각 키는 해시이고 해당 값은 해시를 생성하는 암호입니다. 사전 계산 된 사전을 손에 들고 공격자는 로그인에 필요한 해시를 생성하는 암호를 "즉시"조회 할 수 있습니다.

솔트를 사용하면 사전을 저장하는 데 필요한 공간이 빠르게 증가합니다. 너무 빠르게 암호 사전을 미리 계산하려는 시도가 곧 무의미 해집니다.

최고의 솔트는 암호화 난수 생성기에서 무작위로 선택됩니다. 8 바이트는 실제 크기이며 16 바이트 이상은 용도가 없습니다.


소금은 단순히 "공격자의 일을 더 짜증나게 만드는 것"이상의 역할을합니다. 사전 계산 된 사전 사용과 같은 전체 공격 클래스를 제거합니다.

암호를 완벽하게 보호하려면 또 다른 요소가 필요합니다. 바로 "키 강화"입니다. SHA-1 한 라운드로는 충분하지 않습니다. 안전한 암호 해싱 알고리즘은 계산 속도 매우 느려 .

많은 사람들이 결과를 해시 함수에 피드백하는 키 파생 함수 인 PBKDF2를 사용합니다. 수천 번 합니다. "bcrypt"알고리즘은 유사하며 느린 반복 키 파생을 사용합니다.

해싱 작업이 매우 느리면 미리 계산 된 테이블이 공격자에게 점점 더 바람직해집니다. 그러나 적절한 소금은 그러한 접근 방식을 이깁니다.


코멘트

아래는 질문에 대한 의견입니다.


솔트가 없으면 공격자는 "업데이트 2"에 설명 된 방법을 사용하지 않습니다. 그는 단순히 미리 계산 된 테이블에서 조회를 수행하고 O (1) 또는 O (log n) 시간 (n은 후보 암호 수)에 암호를 얻습니다. Salt는이를 방지하고 "Update 2"에 표시된 O (n) 접근 방식을 사용하도록합니다.

O (n) 공격으로 축소되면 각 시도에 걸리는 시간을 고려해야합니다. 키 강화는 루프의 각 시도에 1 초가 걸릴 수 있습니다. 즉, 1 만 명의 사용자에 대해 1 만 개의 암호를 테스트하는 데 필요한 시간이 3 일에서 3 년으로 늘어납니다 .… 그리고 1 만 개의 암호만으로도 제로 크랙이 발생할 가능성이 높습니다. 그 시간에 암호.

공격자는 PHP가 아닌 가장 빠른 도구를 사용할 것임을 고려해야합니다. 따라서 100 번이 아닌 수천 번의 반복이 키 강화를위한 좋은 매개 변수가 될 것입니다. 단일 암호에 대한 해시를 계산하는 데는 1 초의 많은 시간이 걸립니다.

키 강화는 PKCS # 5의 표준 키 파생 알고리즘 PBKDF1 및 PBKDF2의 일부로, 훌륭한 암호 난독 화 알고리즘을 만듭니다 ( "파생 키"는 "해시"임).

StackOverflow의 많은 사용자 가이 기사를 참조하는 이유는 레인보우 테이블의 위험성에 대한 Jeff Atwood의 게시물에 대한 답변 이었기 때문입니다. 내가 가장 좋아하는 기사는 아니지만 이러한 개념에 대해 자세히 설명합니다.


물론 공격자가 솔트, 해시, 사용자 이름 등 모든 것을 가지고 있다고 가정합니다. 공격자가 myprettypony.com 팬 사이트의 사용자 테이블을 버린 부패한 호스팅 회사 직원이라고 가정합니다. 그는 돌아 서서 당신의 조랑말 팬들이 그들의 citibank.com 계정에서 동일한 암호를 사용했는지 확인할 것이기 때문에 이러한 암호를 복구하려고합니다.

잘 설계된 암호 체계로, 그것은 것 없는 이 사람이 어떤 암호를 복구하기.


1
"사전 공격"이란 Tom이 미리 계산 된 해시-일반 텍스트 테이블이 아닌 알려진 취약한 암호 (예 : 인간 언어 사전에서 바로 나온 암호)를 시도하는 것을 의미한다고 생각합니다. 이 컨텍스트.
Michael Borgwardt

@Michael Borgwardt : 동의합니다. @erickson은 사전 계산 된 사전 공격을 말합니다.
Dirk Vollmar

1
Salt는 사전 계산 된 사전 공격을 차단합니다. 키 강화는 사전 공격을 차단합니다. 보안 암호 인증을 위해 둘 다 함께 사용해야합니다.
erickson 2010-08-25

나는 평범한 영어 테이블을 의미합니다. 이 질문은 해커가 각 사용자 계정에 대해 가능한 모든 해시 조합을 처리하는 것을 막는 방법에 대한 문제를 해결하는 것입니다
Tom Gullen

7

염분의 요점은 공격자의 노력이 상각되는 것을 방지하는 것입니다.

솔트없이 미리 계산 된 해시-암호 항목의 단일 테이블 (예 : 모든 영숫자 5 개 문자열의 MD5, 온라인에서 쉽게 찾을 수 있음)을 전 세계 모든 데이터베이스의 모든 사용자에게 사용할 수 있습니다.

사이트 별 솔트를 사용하여 공격자는 테이블을 직접 계산 한 다음 사이트의 모든 사용자에게 사용할 수 있습니다.

사용자 별 솔트를 사용하면 공격자는 모든 사용자를 위해 이러한 노력을 개별적으로 소비해야합니다.

물론 이것은 사전에있는 정말 약한 암호를 보호하는 데 많은 역할을하지 않지만, 이러한 상각으로부터 합리적으로 강력한 암호를 보호합니다.


1
짧고 정확한 답변-솔트없이 또는 사이트 전체 솔트를 사용하면 동일한 비밀번호로 사용자를 쉽게 찾을 수 있으며 무차별 대입 만하면됩니다. 사용자 별 솔트로는 그렇게 할 수 없습니다.
snemarch aug

6

또한-한 가지 더 중요한 점-USER 특정 솔트를 사용하면 동일한 암호를 사용하는 두 명의 사용자가 감지되지 않습니다-해시가 일치합니다. 그래서 해시는 해시 (salt + username + password) 인 경우가 많습니다.

해시 비밀을 유지하려고하면 공격자가 해시를 확인할 수도 없습니다.

편집-위의 주석에서 요점이 작성되었음을 알았습니다.


1
사용자 별 솔트를 지정하려면 편집해야합니다. 사이트 전체 솔트를 사용하는 사이트에서는 여전히 동일한 암호를 감지 할 수 있습니다.
snemarch aug

@snemarch-예-이 중요한 구별에 대해 대단히 감사합니다!
Dominik Weber

5

레인보우 테이블 공격을 방지하기 위해 솔트가 구현됩니다. 무지개 테이블은 미리 계산 된 해시 목록으로, 해시를 구문으로 훨씬 더 간단하게 변환 할 수 있습니다. 최신 해싱 알고리즘이 없으면 솔팅이 암호 크래킹에 대한 현대적인 예방책으로 효과적이지 않다는 것을 이해해야합니다.

따라서 우리가이 알고리즘으로 발견 된 최근 익스플로잇을 활용하여 SHA1을 사용하고 있다고 가정 해 보겠습니다. 컴퓨터가 초당 1,000,000 해시로 실행되고 있다고 가정 해 보겠습니다 . 충돌을 찾는 데 530 만 년이 걸립니다. . 그래서 예 php 1 초에 300 번 일할 수 있습니다. 우리가 염두에 두는 이유는 누군가가 모든 일반적인 사전 구문을 생성하려고했다면 (2 ^ 160 명, 2007 시대의 공격에 오신 것을 환영합니다) 때문입니다.

여기에 테스트 및 관리 목적으로 사용하는 2 명의 사용자가있는 실제 데이터베이스가 있습니다.

RegistrationTime        UserName        UserPass    
1280185359.365591       briang      a50b63e927b3aebfc20cd783e0fc5321b0e5e8b5
1281546174.065087       test        5872548f2abfef8cb729cac14bc979462798d023

실제로 솔팅 방식은 sha1 (등록 시간 + 사용자 이름)입니다. 계속해서 내 비밀번호를 알려주세요. 이건 프로덕션의 실제 비밀번호입니다. 거기에 앉아서 PHP로 단어 목록을 해시 할 수도 있습니다. 야생으로 가십시오.

나는 미쳤지 않고 이것이 안전하다는 것을 알고 있습니다. 재미를 위해 테스트 비밀번호는test 입니다. sha1(sha1(1281546174.065087 + test) + test) = 5872548f2abfef8cb729cac14bc979462798d023

다음과 같이 전체 무지개 테이블을 생성해야합니다. 27662aee8eee1cb5ab4917b09bdba31d091ab732 위해 단지 이 사용자를. 즉, 실제로 내 비밀번호가 단일 레인보우 테이블에 의해 손상되지 않도록 허용 할 수 있으며, 해커는 테스트를 위해 27662aee8eee1cb5ab4917b09bdba31d091ab732에 대해 전체 레인보우 테이블을 생성하고 briang에 대해 다시 f3f7735311217529f2e020468004a2aa5b3dee7f를 생성해야합니다. 모든 해시에 대해 530 만 년을 생각해보십시오. 2 ^ 80 개의 해시 (20 yottabytes가 훨씬 넘음 ) 만 저장하는 크기를 생각해보십시오 . 그렇게되지 않을 것입니다.

해독 할 수없는 해시를 만드는 수단으로 솔팅을 혼동하지 마십시오. 레인보우 테이블이 모든 사용자 암호 를 번역하지 못하도록 방지하는 수단입니다 . 이 수준의 기술에서는 불가능합니다.


무지개 테이블이 무엇인지 이해하지만 내 질문의 요점을 놓치고 있습니다. 솔팅 알고리즘, 해시 된 암호 및 솔트를 제공했다면 예, 몇 분 이내에 암호가 무엇인지 알려줄 수있을 것입니다.
Tom Gullen

입에 돈을 넣어?
Incognito

물론입니다.하지만 방금 귀하의 예제에서 암호가 무엇인지 말해 주셨습니다. 솔트, 해시 된 암호 및 솔트 + 암호 (비 재귀) 조합 방법 및 암호가 <= 5 개의 소문자 영숫자 (공백 없음 / 특수 문자)이 상자에 무엇이 있는지 알려 드리겠습니다. 당신이 제안한대로 돈을 넣으려면 알려주십시오. 몇 분 동안의 내 의견은 아마도 과소 평가 일 수 있지만 몇 시간 내에 그렇습니다.
톰 Gullen

1
실제로 몇 초 정도면 GPU를 사용하여 " 초당 2300M / s SHA1 해시"로 계산하는 golubev.com/hashgpu.htm 을 참조하십시오 . 1-6 자 범위의 전체 95 개의 ASCII 문자를 사용하여 6 분 이내에 해독 할 수 있습니다. 소문자 영숫자 만있는 경우 길이는 최대 8 자 (25 분 미만)입니다. 10,000 개의 사용자 레코드가있는 데이터베이스를 사용하여 200 초 미만 ((((95 ^ 4) / 2300000000) / 2) * 10000) 내에 4 자 전체 ASCII 암호를 모두 찾을 수 있습니다. (견적 된 것보다 더 많은 오버 헤드와 인용 된 GPU 속도는 아마도 이상적인 상황 일 것입니다).
톰 Gullen

예, 솔팅은 해당 암호를 무차별 대입하는 것을 방지하지 않습니다. 사용자가 약 10 자 암호를 가지고있는 경우 ((10 ^ 5) * (94 ^ 10)) = 10 ^ 24를 생성하기가 더 어렵습니다. 이는 해시가없는 10 ^ 19보다 훨씬 어렵습니다. 다시 말하지만, 하나의 암호를 어렵게 만드는 것이 아니라 사전 처리 된 레인보우 테이블을 사용하여 모든 암호를 해독 할 수 없게 만드는 것입니다. (그리고 여기에서 내 수학을 확인하지만 모든 사람의 암호에 대해 10 ^ 25 / 2300000000 / 60 / 60 / 24 / 365 / 1000 = 137 869 ~ milinea를 믿습니다). 더 강력한 암호를 원하면 솔트하지 않고 Diffie–Hellman 키 교환과 같은 것을 사용합니다.
Incognito

3

사전 공격의이면에있는 아이디어는 해시를 가져 와서이 해시가 계산 된 암호를 찾는 것입니다. 해시 계산 없이 해시를 가져 와서이 입니다. 이제 솔트 된 암호로 똑같이하십시오-할 수 없습니다.

솔트를 사용하지 않으면 데이터베이스에서 조회하는 것만 큼 쉽게 비밀번호를 검색 할 수 있습니다. 솔트를 추가하면 공격자가 가능한 모든 비밀번호의 해시 계산을 수행합니다 (사전 첨부의 경우에도 공격 시간이 크게 늘어남).


OP의 시나리오에서 공격자 데이터베이스의 솔트를 가지고 있으며 "사전"의 모든 항목에 대해 모든 솔트를 시도해야합니다. ... 나는 생각한다.
FrustratedWithFormsDesigner

2

간단히 말해서 솔팅없이 각 후보 암호는 동일한 알고리즘을 통해 암호가 해시되는 "알려진 세계"(손상된 데이터베이스 모음)의 모든 사용자에 대해 확인하기 위해 한 번만 해싱하면됩니다. 솔팅을 사용하면 가능한 솔트 값의 수가 "알려진 유니버스"의 사용자 수를 상당히 초과하는 경우 각 후보 암호는 테스트 대상인 각 사용자에 대해 별도로 해시되어야합니다.


2

단순히 소금을 넣는다 고해서 해시가 공격 (bruteforce 또는 사전)으로부터 차단되는 것은 아닙니다. 공격자는 솔팅 알고리즘 (적절하게 구현되면 더 많은 반복을 사용함)을 찾거나 알고리즘을 bruteforce해야합니다. 이는 매우 간단하지 않으면 거의 불가능합니다. Salting은 또한 무지개 테이블 조회 옵션을 거의 완전히 폐기합니다 ...


1

소금은 무지개 테이블을 만든다 단일 암호 해시를 크래킹하기 훨씬 더 어렵게 만들기 때문에 공격을 훨씬 더 어렵게 만듭니다. 숫자 1의 끔찍한 암호를 가지고 있다고 상상해보십시오. 레인보우 테이블 공격이 즉시이를 깨뜨릴 것입니다.

이제 db의 각 암호가 많은 임의 문자의 긴 임의 값으로 솔트되어 있다고 상상해보십시오. 이제 형편없는 암호 "1"이 db에 1의 해시와 임의의 문자 (솔트) 묶음으로 저장되므로이 예제에서 무지개 테이블에는 다음과 같은 해시가 있어야합니다. 1

따라서 소금이 안전하고 무작위라고 가정하면 () % ISLDGHASKLU ( % # % #) 해커의 무지개 테이블에는 1 * () % ISLDGHASKLU (* % # % #에 대한 항목이 있어야합니다. 이제 무지개 테이블을 사용합니다. 이 단순한 암호조차도 더 이상 실용적이지 않습니다.


업데이트 # 2를 참조하십시오. 단순히 원시 암호를 갖고 각 사용자 레코드의 솔트에 대한 모든 해시를 계산합니다.
Tom Gullen

2
물론 Tom, 동의하지만 요점은 솔트를 사용하는 경우 암호 대해 해커가 시간이 많이 걸리는 추악한 프로세스를 한 번씩 수행해야한다는 것 입니다. 따라서 소금은 무지개 테이블 사용을 더 어렵게 만듭니다.
Cory House

3
@Tom Gullen : 솔트 레인보우 테이블 생성은 사이트 전체 솔트가 사용되는 경우에만 가능합니다. 사용자 별 솔팅은 레인보우 테이블 공격을 거의 쓸모 없게 만듭니다.
snemarch
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.