레인보우 테이블

2020년 5월 14일 | 사이버

레인보우 테이블은 미리 계산된 인증 데이터베이스를 사용하여 암호화 해시 함수를 해킹하고 평문 암호를 알아내는 데 사용되는 리소스였습니다 . 레인보우 테이블 기반 솔루션은 암호 해시를 빠르게 해독하는 데 필요한 정보를 조회하는 알고리즘을 사용합니다. 최신 암호 솔팅 및 해싱 알고리즘 덕분에 레인보우 테이블은 대부분 무용지물이 되었지만, 여전히 많은 애플리케이션이 이러한 도구를 사용하지 않고 게으름이나 중요한 세부 사항에 대한 부주의로 인해 단일 해시 암호에 의존하고 있습니다.

레인보우 테이블이나 기타 해시 크래킹 방법을 사용하는 아이디어는 인증 데이터베이스에서 비밀번호 해시를 사용하는 데서 비롯되었습니다. 인증에 비밀번호를 사용하는 모든 시스템은 비밀번호를 어떤 형태로든 저장해야 합니다. 최악의 경우, 애플리케이션 개발자가 비밀번호를 평문으로 저장하게 되어 모든 등록된 사용자의 비밀번호가 해커나 내부 시스템 관리자의 무단 접근에 매우 취약해질 수 있습니다. 이러한 잘못된 관행은 수십 년 동안 알려져 왔지만, 온라인 애플리케이션에서는 여전히 흔히 발생합니다.

일부 프로그래머들이 하는, 다소 무의미하다고 할 수 있는 일은 비밀번호에 대한 단일 해시 계산을 수행하는 것입니다. 비밀번호를 무작위 문자열로 변환하는 일반적인 해싱 알고리즘이 있지만, 실제로는 레인보우 테이블을 사용하여 역공학하기가 매우 간단합니다. 시스템에 인증할 때 입력하는 비밀번호는 비밀번호 데이터베이스에 비밀번호를 저장하는 데 사용된 것과 동일한 알고리즘을 사용하여 해시됩니다. 해시가 일치하면 인증에 성공한 것입니다. 바로 이 부분에서 레인보우 테이블이 사용됩니다.

레인보우 테이블은 1자부터 7자 또는 8자까지의 평문 비밀번호의 모든 단방향 해시값을 저장합니다. (단순 해싱 알고리즘의 경우 8자 레인보우 테이블을 저장하는 데 최대 32페타바이트의 데이터베이스 공간이 필요합니다!) 해커가 단순 비밀번호 해시 캐시를 훔치면 레인보우 테이블에서 해시값을 조회하여 평문 비밀번호를 찾을 수 있습니다.

레인보우 테이블이 대부분 사라진 이유는 무엇일까?

최대 32자까지 솔팅(salting)을 적용하는 비밀번호가 등장하면서, 레인보우 테이블로는 이러한 비밀번호를 해독할 수 없게 되었습니다(출처: Rainbow Tables are Dead ). 더 중요한 것은, 많은 표준 바이너리 프로그램들이 비밀번호에 대해 반복 해싱을 수행한다는 점입니다. 이는 솔팅된 비밀번호를 정해진 횟수만큼 반복해서 해싱하고, 예를 들어 764번째 해싱 값과 같은 최종 해시값을 데이터베이스에 저장하여 애플리케이션 인증 시 비교하는 방식입니다. 레인보우 테이블로는 이러한 비밀번호를 해독할 수 없습니다.

왜 레인보우 테이블은 모두 죽지 않은 걸까?

해커가 비밀번호 캐시를 훔칠 때 레인보우 테이블을 사용하여 상위 100개 비밀번호를 조회하면 비밀번호가 N번 솔팅되고 해싱되었는지 빠르게 확인할 수 있습니다. 일치하는 비밀번호를 찾으면 프로그래머가 게을러서 비밀번호를 솔팅하지 않았는지, 반복적으로 해싱하지 않았는지, 아니면 둘 다 하지 않았는지 역추적할 수 있습니다. 개발자들이 이러한 중요한 단계를 너무 자주 건너뛰는 바람에 해커는 이제 간단한 레인보우 테이블을 사용하여 비밀번호를 역공학하여 얻을 수 있습니다.

이는 중소기업에게 무엇을 의미할까요?

레인보우 테이블은 솔트되지 않은 단일 해시 비밀번호를 해독하는 빠르고 효과적인 방법입니다. 중소기업(SMB)에서 애플리케이션을 개발하는 경우 비밀번호가 어떻게 저장되는지 반드시 문의하세요. 개발자에게 SALT 값(8자리면 작지만 32자면 충분합니다)을 문의하고, 해시된 값을 저장하기 전에 비밀번호를 몇 번 반복하는지 물어보세요. LastPass는 마스터 비밀번호에 대해 10만 번 이상 해싱을 수행합니다. 조직에 과도할 수 있지만, 수백에서 수천 번 정도는 필요할 것입니다.

일반적인 솔팅 및 해싱 함수에는 " Argon2 , scrypt , bcrypt 및 PBKDF2 "가 있습니다.

무엇을 하든 이를 애플리케이션 개발의 중요한 요구 사항으로 간주해야 합니다. 비밀번호 스키마에 SSO를 구현할 수 없고 비밀번호 해시를 저장해야 하는 경우, 이 글에서 언급한 도구를 사용하여 비밀번호 데이터베이스에 솔트 처리를 하고 반복적으로 해싱해야 합니다.