최근 모 대기업에서 운영하는 서비스에서 개인정보가 유출되어 올라온 공지사항이다. 특정 기업을 비난하고자 하는 것이 아니므로 기업명은 제거하였다.
과연 비밀번호가 일방향 암호화 되어 있으니 유출되어도 안전할까?
일방향 암호화는 유출시에 피해를 최소화하기 위한 목적으로 한다고도 볼수 있다. 하지만 말 그대로 피해를 최대한 방지해보기 위한 것이지, 이를 통해 안전이 보장된다고 보는 것은 조금 다른 이야기이다. 아래는 다소 기술적인 내용이 포함되어 있으나 컴퓨터공학과 학생 정도면 쉽게 읽을 수 있는 수준이다. 당신이 IT와 관계없는 일반인이라면 그냥 가장 아래쪽의 결론만 읽으셔도 무방하다.
1. 일방향 암호도 뚫린다.
일방향 암호에 사용되는 해시는 복호화가 불가능한 구조로 되어 있지만 그렇다고 해시를 통해 내 비밀번호를 못 알아낼 것이라 보장할 순 없다. 해시에 사용되는 일반적인 공격은 무차별 대입이다. 숫자, 문자, 특수문자로 구성된 모든 값을 하나씩 대입해보며 결과값이 같은 값을 찾는 것인데, 요즘의 컴퓨팅 파워와 분산·병렬처리 기술을 이용하면 모든 조합을 다 대입시켜 보는 것이 그렇게 불가능한 일도 아니다. 국내 최소 기준인 영문 + 숫자 + 특수문자로 이루어진 암호 8자리는 11,969,016,345가지 경우의 수를 가진다. 현재 기술로도 초당 수십만~수억건의 해시를 대입해 볼 수 있음을 감안하면 120억건의 경우의 수는 너무나도 약하다. 그리고 MD-5나 SHA-1처럼 알고리즘 자체의 취약점이 발견된 경우에는 이를 이용해 충돌을 훨씬 빠르게 찾아낸다.
위 내용에 대해선 많은 반론이 나올 수 있다. 비밀번호의 길이가 조금만 더 길어도 무차별 대입은 무의미해 질 수 있다는 점, salt의 사용, 중복 해싱, 해시 알고리즘의 강도 등에 따라 무차별 대입은 현실성은 극도로 낮아질 수 있다는 점 등. 이 부분은 뒤에서 다시 설명할 것이다.
하지만 왜 우리가 비밀번호를 5번 이상 틀리면 계정을 잠궈 버리는지, 왜 공인인증서의 탈취에 대해 심각하게 생각하는지 생각해보아야 한다. 무차별 대입이 자유로운 상황에선 '안전'을 단정짓긴 어렵다. 이 유출된 DB가 당장 현재의 기술로, 당장 노출된 정보만으로 활용이 될거라고 생각해선 안된다. 유출은 알게모르게 많은 곳에서 이루어지고 있고 해커들은 다크웹 등에서 이런 DB를 사고팔며 여러 정보를 조합해 활용할 수 있다. MD-5나 SHA-1처럼 당시엔 보편적으로 사용했던 기술들이 지금은 취약한 기술이 되었듯이 SHA-2 도 그렇게 되지 않으리란 보장이 없다.
2. 당신의 비밀번호는 이미 취약하다.
무차별 대입 공격의 현실성에 대해선 의견이 분분할 수 있다. 하지만 난 여기서 보안이 다소 취약하게 관리되는 시스템과 보안이 다소 미숙한 일반인들까지 모두 고려를 해야 한다고 생각한다.
해커가 항상 무식하게 무차별 대입을 통해 비밀번호를 찾아내는 것은 아니다. 무차별 대입이 단순히 0부터 9까지 a부터 z까지 대입해보는 것이 아니다. 일반적으로 사람들이 비밀번호에 활용하는 패턴(첫 번째 글자는 문자, !@, 1!) 등을 이용하면 그 경우의 수를 훨씬 줄일 수 있다. 더군다나 당신이 혹여라도 중요한 사람이고 APT의 대상으로 해커들의 타겟이 된 상황이라면 여러 사회공학적 기법 등으로 비밀번호를 유추하여 해시 충돌을 찾는 상황도 고려하여야 한다.
그리고 우리은행 크리덴셜 스터핑 사건에서 볼 수 있듯이 이미 상당한 수의 아이디 비밀번호가 이미 노출된 상황이고 유출된 비밀번호들로 구성된 패스워드 사전들이 방대하게 구축되고 있음을 감안하면 당신의 비밀번호는 정말 나만 사용하는 안전한 비밀번호라고 할 수 있는지에 대해 한번 돌아볼 필요가 있다.
반대로 생각하면 약 100만명의 암호화된 비밀번호가 있는데 여기 취약한·유출된 비밀번호 수십만 개씩을 대입시켜 본다면 누군가는 그 취약한 비밀번호를 사용하고 있다는 것이 확인되지 않을까?
3. 솔트(salt)와 중복 해싱
해시의 안전성을 강화하기 위해 가장 보편적으로 사용되는 것이 솔트(salt)와 중복해싱이다. 수십비트 이상의 솔트값을 사용하여 XOR연산까지 하며 여러번 반복적으로 해싱을 할 경우, 무차별 대입공격으로 실제 비밀번호를 유추한다는 것은 거의 불가능하다고 볼 수 있다.
하지만 솔트값이 과연 안전하게 보관되었으냐는 또 다른 문제이다. 아직까지도 많은 시스템에서 솔트값을 하드코딩해두거나 properties 파일에 평문으로 저장해둔다. 그리고 각각의 유저의 개별적인 해싱값 보호를 위해 솔트값을 유저 테이블에 하나의 칼럼으로 구성하여 저장하는 경우도 있는데, 이는 DB가 통째로 털린 경우엔 전혀 역할을 하지 못한다. 솔트값이 노출된 경우 중복해싱 패턴을 알아내는 것은 일반적으로 쉽다.
정보주체인 우리 입장에서는, DB가 털려서 회원 테이블의 정보가 모두 유출되어 버린 기업이 솔트값은 안전하게 보호했고 해싱 패턴은 잘 설계했다고 무작정 신뢰할 수는 없을 것이다. 더군다나 해시값 유출은 유출 통지 대상도 아니라는 것이 중요하다. 이런 부분은 정책 입안 과정에서 고려할 필요도 있다.
결론
해킹을 당한 기업의 보안 담당자가 이렇게 말할 순 있다. "DB가 털리긴 했는데 우리는 안전한 난수발생기로 만든 32비트 솔트값을 HSM에 저장하고 SHA-2 알고리즘으로 복잡한 패턴의 중복 해싱을 사용하고 있기 때문에 비밀번호가 드러날 가능성은 없다"라고. 이런 말은 쉽게 반박할 수 없다. 하지만 침해사고 조사를 나가서 제대로 검증을 해보지 않으면 온전히 믿을 수도 없는 말이다. 더 중요한 것은 대부분의 기업에선 개인정보가 유출되었을 때 저렇게 구체적으로 설명을 늘어놓지 않는다는 것이다. 그저 '일방향 암호화되었으니 안전합니다.'라는 말뿐이다. 이렇게 되면 비밀번호 보안을 잘 하고 있는 기업과 그렇지 못한 기업을 구분할 수도 없다.
"일방향 암호화되었기 때문에 안전합니다." 물론 해당 기업에선 정말 자신이 있을 수도 있지만, 정보주체(이용자) 측면에선 저 말을 믿지 말라. 이 말을 하기 위해 긴 글을 적었다. 믿지 말라고 해서 거짓말한다고 단정짓고 소송을 제기하란 것이 아니다. 그냥 변동 없이 오랫동안 사용만 해도 안전하지 못한 것이 비밀번호인데, 저렇게 유출까지 된 상황이라면 내 비밀번호는 더 이상 안전하지 않다고 생각하고 바꾸는 것이 당신을 위해 이롭다는 것이다.
그리고 기업에서도 "안전합니다"라기 보다는 "일방향 암호화된 비밀번호는 이론적으로 역변환될 수 없습니다. 하지만 안전을 위해 비밀번호를 변경하시는 것을 적극 권장합니다." 정도로는 적어줘야 하지 않을까 싶다.
'IT 기술 정보' 카테고리의 다른 글
분산ID(DIDs)의 본질은 블록체인이 아니다. (0) | 2021.10.25 |
---|---|
데이팅 서비스(소개팅 앱) 해킹 방지 점검 사항 - 운영자 & 이용자 필독! (1) | 2021.10.17 |
온라인 서비스 잘못된 구현 사례 (0) | 2021.08.25 |
패스워드 길이와 복잡도에 관한 고찰(NIST 800-63B) (0) | 2021.08.20 |
올바른 패스워드 작성규칙(길이 vs 복잡도) (2) | 2021.08.20 |