레인보우 테이블

공부하게 된 계기

---

갑자기 왜 공부하게 됐냐면,,,

현재 만들고 있는 서비스에서 사용자의 비밀번호를 저장할 때, 평문에 Salt 값을 붙인 다음 Hashing(해싱)을 해서 DB에 저장 하도록 구현했다.

평문이 아니라 해시값을 저장하는 이유는 혹여나 악의적인 공격자에 의해 노출되었다고 했을 때, 실제 비밀번호는 알아내지 못하게 하기 위함이다.

 

여담이지만 요즘은 비밀번호 찾기를 하면, 기존의 비밀번호를 pas*w*rd 이런 식으로 알려주는 게 아니라 무조건 비밀번호를 변경하게 한다.

그 이유가 해시값을 저장하기 때문에 원래 비밀번호가 뭐였는지 알지 못하기에, 알려줄 수가 없기 때문 !

 

Salt 값을 사용하는 이유는 예전에 보안 시간에 레인보우 테이블이라는 공격법을 배웠었는데,

이 레인보우 테이블 공격에 대응하기 위해서 음식에 소금을 치듯이 비밀번호에 Salt를 붙여서 해싱 을 하는 것이라고 배웠다.

 

나의 착각

---

레인보우 테이블에 대한 오해

왜인지 모르겠지만, 나는 레인보우 테이블 공격과 브루트 포스 공격을 비슷한 개념으로 생각을 하고 있었다.
그런데 Salt값을 붙이는 게 왜 브루트 포스 공격에 대한 방어일까? 라고 생각했다.

왜냐하면 Salt값을 사용하려면 각 사용자에 대한 Salt값을 저장하고 있어야 사용자가 비밀번호를 전송했을 때,
같은 Salt값을 사용해서 해싱을 한 후 저장된 해시값(비밀번호)과 비교를 할 수 있다고 생각했다.

 

• 내가 생각한 것은 위와 같은 상황이다
• 공격자가 어짜피 평문에 대해 브루트포스 공격을 하면 알아서 서버에서 Salt를 붙여서 해싱을 한 다음에 비교 를 하게 되는데 이게 왜 브루트 포스 공격에 대한 방어지? 라고 생각했던 것이다

 

레인보우 테이블

---

오해를 풀기 위해서 레인보우 테이블에 대해서 다시 공부를 했다

• 레인보우 테이블을 사용하는 이유는 공격자가 비밀번호를 탈취했을 때, 해당 비밀번호가 평문이 아니라 해시값으로 저장되어 있는 경우에 평문을 빠르게 알아내기 위해서 이다
• 사용자들이 많이 사용하는 비밀번호에 대해서 많은 해시 함수(SHA-256, MD5, ... 등등)에 대해서 미리 해시값을 만들어서 테이블로 저장 해두고 해시값을 탈취했을 때, 빠르게 평문을 알아낼 수 있게하기 위함이다.
• 브루트 포스 공격으로 분류한다면 그렇다고 할 수 있지만, 애초에 비밀번호를 무작위로 대입해서 맞히는 게 아니라 해싱된 값을 탈취했을 때 평문을 알아내기 위한 공격법이다

 

나는 공격 방법 자체를 잘못알고 있었던 것이다.

 

Salt

---

Salt가 레인보우 테이블에 대한 방어법이 되는 이유

• 레인보우 테이블은 평문에 대한 해시값을 막 만들어두고 이걸 이용해서 해시값을 보고 평문을 유추하는 공격이라고 했다
• 그런데 Salt값을 붙여서 해싱을 하게 되면, 같은 비밀번호에 대해서도 해시값이 다르게 나오는 것이다
• 공격자 입장에서 Salt값이 어떤 값일지 모르기 때문에 엄청난 경우의 수에 대해 해시값을 미리 만들어두어야 하고, 그럼 테이블의 크기가 커지기 때문에 공격의 대응책이 되는 것이다
  • Salt가 32bit라고 하면, 테이블의 크기가 2^32배 커지게 된다

 

브루트 포스 공격을 막는 방법?

---

그렇다면 내가 원래 우려했던 브루트 포스 공격은 어떻게 방어할 수 있을까?

• CAPTCHA 를 사용해서 공격자의 리소스를 소비시키거나
• 비밀번호 시도 횟수 제한 을 걸어서 브루트 포스 공격을 못하게 할 수 있다

 

공격 방식에 대해 오해를 해서 혼자서 공격자와 쉐도우 복싱을 했는데, 덕분에 더 정확히 알 수 있어서 오히려 좋았다

 

Reference

---

Rainbow table - Wikipedia

Rainbow Table Attack 알아보기

Why CAPTCHA Pictures Are So Unbearably Depressing