U-02) 패스워드 복잡성 설정

 

 

이번 글에서는 주통기 점검 가이드의 "패스워드 복잡성 설정" 점검 항목에 대해서 이야기해보고자 합니다. 이번 항목은 지난번 다뤘던 항목인 "01) root 계정 원격 접속 제한"에 비해서는 시스템 정책 측면이 강하기도 하고, 패스워드를 복잡하게 설정해야 해킹을 당할 확률이 낮아진다는 건 모두들 아실거라 넘어갈까 생각도 했었는데요. 제가 정보보안기사 시험을 봤던 해인 2018년에 실기 서술형에서 비밀번호 작성규칙이 출제되었는데, 여기에 나오는 패스워드 복잡성 설정과도 연관이 되어있어서 이 부분도 함께 언급하면서 간단히 정리를 해보겠습니다.

 

 

먼저 주통기 점검 가이드에 나온 취약점 개요를 간단하게 정리를 해봤습니다. 그런데 지금 KISA에 올라온 주통기 점검 가이드에서는 오타를 수정하지 않은 것인지 양호와 취약 기준이 동일하게 나와있는데, 아마 추후 수정이 될 것으로 보이며 여기서 눈여겨 봐야할 것은 판단 기준인데요. 제가 보기엔 2021년에 개정이 된 버전보다 2017년도 버전이 오히려 판단 기준을 좀 더 명확하게 쓰지 않았나 생각됩니다.

 

2017년 버전에서는 영문, 숫자, 특수문자를 조합하여 2종류 조합 시 10자리 이상, 3종류 이상 조합 시 8자리 이상으로 설정해야 양호로 판단한다고 나와있죠. 사실 이 기준은 개인정보보호위원회에서 발간한 "개인정보 안전성 확보조치 기준"에 따른 부분인데, 아직 법이 바뀌지 않았음에도 불구하고 위와 같이 판단 기준을 바꾼 것을 보면 어떤 이유가 있을 것 같은데요. 만약 정보보안기사 시험에 비밀번호 작성규칙을 적으라고 나온다면, 개인정보보호법인지 주통기 점검 가이드 기반인지 구분하셔서 쓰시길 바랍니다.

그래서 위의 판단 기준 가지고 해당 항목이 양호인지 취약인지 확인하는 방법은 저번 점검 항목과 마찬가지로 특정 설정 파일에서 적절한 옵션이 설정되어 있는지 보는겁니다. 주통기 점검 가이드에서는 리눅스 서버 운영체제 중 레드햇 배포판을 기준으로 설명하고 있는데, 지난 번에 말씀드렸다시피 운영체제마다 그리고 배포판 및 버전마다 설정 파일의 위치와 옵션 등이 상이하기 때문에 구글 검색을 통해 점검하는 환경에 맞춰서 스크립트를 작성하셔야 합니다. 스크립트를 구성하는 방법은 지난 번과 동일하기 때문에 이번 글에서는 넘어가도록 하고, 여기서는 모두가 아시겠지만 왜 비밀번호를 복잡하게 구성하는 것이 안전한지를 간단히 개념적으로 설명하고 마치도록 하겠습니다.

2000년 대 초기에는 웹 사이트에서 회원가입을 할 때 패스워드를 숫자로만 구성하거나 숫자와 영문만으로 구성해도 가입할 수 있었는데요. 그런데 언젠가부터 패스워드를 숫자, 영문 뿐만 아니라 특수문자를 섞어 만들어야 안전하다면서 만들기도, 기억하기도 어렵게 되었죠. 어떻게 보면 개인 계정의 패스워드야 복잡하게 구성하지만, 기업에서 사용하는 리눅스와 같은 서버의 패스워드는 그렇게 크게 복잡하게 만들지 않는 경우가 많습니다. 심지어 잊어버릴까봐 qwer1234와 같이 패스워드를 기억하기 쉽게 만들거나 기업의 브랜드명을 포함해서 유추하기 쉽게 만드는 경우가 많죠. 실상 이런 사소한 부분 때문에 기업에서 침해사고가 발생하기도 하니 주의하셔야 합니다.

그리고 많은 분들이 보안을 처음 공부할 때 비밀번호 안전성을 확인하기 위해서 John the ripper와 같은 패스워드 크랙 툴을 사용해본 적이 있을 거라 생각합니다. 크랙 툴로 숫자로 구성된 4자리 패스워드는 금새 찾아낼 수 있고 숫자와 영문으로 구성된 8자리까지는 어느 정도 시간이 걸려 알아낼 수 있지만, 특수문자가 포함되고 9자리 이상으로 패스워드가 만들어지면 푸는데 몇 년 이상이 걸리게 되는데요.

 

패스워드 크랙 툴의 원리가 0부터 순차적으로 대입을 하거나 사전 공격 또는 Brute Force와 같은 무차별 대입 공격을 하는 것이기 때문에, 경우의 수를 무한하게 만들어주면 패스워드를 유추할 수 있는 시간을 증가시킬 수 있겠죠. 물론 리눅스 서버의 경우 패스워드를 5번 이상 틀리면 계정을 잠궈버리는 임계값을 설정하는 부분이 있기 때문에, 패스워드를 어렵게 만들었다면 계정 정보가 유출되지 않고서야 크랙 툴을 이용해서 들어오는 경우는 거의 없을테지만 그래도 신경을 써야 하는 부분입니다.

어느 정도 이야기를 다 한 것 같은데 여기서 끝내긴 너무 짧아서 사담을 한 가지 더 할까 합니다. 보통 한국의 웹 사이트에서는 90일마다 비밀번호를 변경하라고 하는데, 최근 미국의 국립표준 기술연구소인 NIST에서 연구한 자료에 따르면 오히려 비밀번호를 자주 바꾸는 것이 문제가 된다고 합니다. 이전까지는 해킹된 사이트에서 유출된 개인정보를 다른 사이트에 대입하는 공격인 "크리덴셜 스터핑" 문제 때문에 비밀번호를 주기적으로 변경하라고 했었는데요.

 

지금은 오히려 잦은 변경이 사용자가 비밀번호를 기억하기 어렵게 만들어 보안 효과를 저해한다 말하고 있죠. 그래서 비밀번호가 유출되었을 때만 변경하도록 하고, 또 오히려 안전한 비밀번호는 짧고 어려운 비밀번호보다 쉽고 긴 길이의 패스워드가 더 풀기 어렵다고 하는데, 위에서 말씀드린 경우의 수를 무한히 늘려줘서 풀기 어렵게 만드는 것이라 생각하면 좋을 것 같습니다.

이번 "패스워드 복잡성 설정" 점검 항목에서는 패스워드 정책을 설정할 때 세세한 옵션에 대해 이야기를 하지 않는데요. 저번 글에서는 어느 정도 옵션에 대해서 상세히 설명하고 넘어갔지만, 이번 점검 항목에서 나오는 한 번 읽어보면 딱 알 수 있기도 하고 추후에 비슷한 내용이 나오기 때문에 생략하고자 합니다.

 

실제 취약점 점검을 하다보면 대부분 설정 파일의 위치나 옵션 등을 외워서 하기보단, 대부분 가이드와 필요할 때마다 구글링을 더 많이 하기 때문이죠. 각 옵션의 세세한 정보보다는 해당 점검 항목에 대한 필요성과 개념을 말씀드리는게 오히려 더 좋을 것 같아서, 앞으로 쓰는 글도 이런 기조를 이어가고자 합니다. 그럼 이번 글은 여기서 마치고 "계정 잠금 임계값 설정" 점검 항목에 대한 내용으로 돌아오도록 하겠습니다. 감사합니다.