심심해서 하는 블로그 :: [보안] Salted hash / Bloom Filter

1. Rainbow Table attack

답지를 들고 있단다.

앞서 비밀번호는 대부분 해시함수를 사용하여 그 결과 값을 데이터베이스에 저장한다고 했다. 따라서 복호화가 불가능한 상태라 평문(비밀번호)의 내용을 관리자한테까지 숨길 수 있는 장점을 가지고 있다. 이에 따라 공격자들은 사전에 해쉬함수에 입력한 값과 해쉬 결과 값을 저장한 일종의 정답지(Rainbow Table)를 가지고 비밀번호를 확인 할 수 있게 되었다. 이런 공격 우연하게 같은 비밀번호를 사용하는 경우에 여러 계정이 동시에 피해를 볼 수 있는 단점이 있다. 따라서 이 공격에 대안으로 Salted hash가 등장하였다.


2. Salted hashed

양념을 촵촵촵

기존에는 패스워드만 해시함수에 통과시켰으나 최근에는 가입 시간이나 난수(Random Number)를 비밀번호와 같이 해시 값에 포함한다. 이 때 추가적으로 포함된 가입 시간이나 난수를 Salt라고 한다. 치킨에다가 양념을 어떤 것을 사용하냐에 따라 맛이 달라지 듯이 서로 다른 계정이 같은 비밀번호를 사용하더라도 Salt가 다르면 완전 다른 해시 값이 달라지며, 설령 같은 해시 값을 같더라 하여도 Salt 값이 전혀 다르기 때문에 평문을 유추하기 힘들다. 이 Salt는 해쉬 결과 또는 Salt 평문을 패스워드 관리 테이블에 같이 보관한다.


Salted hash의 경우 Salt의 길이가 길면 길수록 무차별 대입공격이 강력하다. OpenBSD는 Blowfish라는 블록 암호화 기법을 가지고 있으며 128bit의 Salt를 사용하여 192비트의 해시 값을 만들어 낸다.


시간을 끌자

해시 함수는 암호화보다 소요하는 시간이 짧다. 따라서 암호문을 무차별 대입으로 푸는 것보다 해시함수에 무차별로 대입하는 것이 소모하는 시간이 짧아 이 시간을 늘려야 할 필요성이 있다. 이에 따라 개발자들은 해시함수를 1000번이상 반복으로 실행하여 고의적으로 시간을 늦추려 하고 있다. 


3. Bloom Filter

사용자 교육의 한계

뉴스에서 보안 사고가 발생하여도, 청개구리 같은 사용자들이 많다. 비밀번호를 길고 자연어 사용을 제한하고 취약한 비밀번호 사용을 금지해도 외우기 귀찮고 손에 안 익는 비밀번호를 사용하기 싫어서 무시하고 사용하며, 일정 주기마다 비밀번호를 변경하라는 메세지가 뜨면 "다음에 할게요~ㅎㅎ" 하고 그냥 넘어가 버리는 경우도 많다. 따라서 말 안듣는 사용자를 교육시키기보다 애시당초 시스템에서 보안이 취약한 비밀번호에 대하여 거절을 하게 만든다.


너만 갖고 있냐?? 나도 갖고 있어!!

Rainbow Table은 공격자도 가질 수 있지만, 개발자들 또한 해당 테이블을 가질 수 있다. 따라서 개발자들은  
사용자가 회원가입할 때 Rainbow Table에 있는 비밀번호에 대하여 사용을 금지하는 방법을 선택하는데 이러한 과정을 Proactive Password Checking이라 하며 금지된 비밀번호를 걸러 내는 필터를  Bloom Filter라고 한다. 이 방법을 사용하면 사용자는 취약한 비밀번호를 사용이 금지되어지며 공격자가 가지고 있는 패스워드 사전도 취약하게 된다. 설령 공격자가 갱신을 한 패스워드 사전을 가지고 있다 하여도 개발자가 해당 사전을 역시 수집이 가능하므로 금지 비밀번호를 갱신하면 된다.


,