회원가입을 하면 다양한 비밀번호 규칙을 마주하곤 합니다. 특수문자를 입력해야 하는 서비스, 특수문자와 대문자를 입력해야 하는 서비스, 그리고 특정 특수문자를 입력할 수 없는 서비스까지.
그리고 저희는 의문을 가지게 됩니다.
왜?
궁금증에서 나오는 의문이었습니다. 처음에는 '왜 특정 특수문자만 쓸 수 있는가'에서 시작된 의문이었죠. 그게 더 안전한가? 다른 특수문자들은 오류가 발생하나? 그럼 굳이 제한을 두고 있지 않은 내 회원가입 API는 좋지 않은 API인가?
그리고 의문은 의문을 불러왔습니다. 비밀번호 규칙은 왜 서비스마다 다르며, 과연 그 중 뭐가 옳은 것인가! 그러니까, 어떤 비밀번호가 안전할까? 나는 회원가입 API를 만들 때 어떤 제약을 거는 게 좋지?
* 해당 글은 4년전에 쓴 글을 다듬어 재발행하는 글입니다.
여기 개인 정보의 기술적 관리적 보호조치 기준 제 4조가 있습니다.
여기서 저희가 확인해야 할 것은 8항입니다.
⑧ 정보 통신 서비스 제공자등은 개인정보 취급자를 대상으로 다음 각 호의 사항을 포함하는 비밀번호 작성 규칙을 수립하고, 이를 적용/운용하여야 한다.
- 영문, 숫자, 특수문자 중 2종류 이상을 조합하여 최소 10자리 이상 / 또는, 3종류 이상을 조합하여 최소 8자리 이상
- 연속적인 숫자나 생일, 전화번호 등 추측하기 쉬운 개인정보 및 아이디와 비슷한 비밀번호는 사용하지않는 것을 권고
- 비밀번호에 유효기간을 설정하여 반기별 1회 이상 변경
영문, 숫자, 특수문자를 포함하고 90일 주기로 비밀번호 변경이라는 규칙은 저희가 가장 많이 보는 보편적인 그런 규칙들입니다.
대부분의 서비스가 개인 정보 위원회에서 정한 규칙을 따르고 있다는 것을 알았습니다. 그렇다면 이런 규칙들은 그래서 왜, 어떻게 나오게 되었을까요?
이런 규칙들은 사실 NIST에서 2003년 발표한 Digital Identity Guidelines 내용 중 일부입니다.
NIST는 미국 국립 표준 기술 연구소로 미국 내의 표준 업무를 담당하는데요, 미국을 비롯한 세계 각국에서도 이 가이드라인을 따르며, 하나의 보편적인 규칙이 된 것입니다. 🚀
해킹 당하고 싶지 않으면 대문자, 소문자, 숫자, 특수문자를 써서 패스워드를 만들어라
- Bill Burr, Tim Polk, Donna Dods
😮 그러나
2017년 해당 규칙을 만든 Bill Burr는 WSJ 인터뷰에서 이런 규칙이 비밀번호 보안 수준을 높이는 데 별 도움이 되지 않는다고 말했습니다. 많은 이들의 불편과 시간 낭비를 유발했다면서 '내가 했던 일을 후회한다'며 사과하기도 하였어요. 😅
그리고 2021년, NIST는 해당 가이드라인이 오히려 보안에 취약할 수 있다는 사실을 인정하고 이에 개정된 보고서를 공개합니다.
개정 작업을 맡은 NIST 표준 및 기술 고문 Paul Grassi는 특수문자 입력이나 만료기간같은 조건이 별로 도움이 안 되었다며, 실제로 사용성에 부정적인 영향을 주었다고 말하였습니다.
왜 Bill Burr는 후회하고, 2004년의 가이드라인은 오히려 보안에 취약점을 줄까요? 그저 옛날에 만든 규칙이었어서 그런걸까요?
아닙니다. 2004년 만들어진 가이드라인의 실패는, 바로 이용자들의 성향을 고려해 규칙을 만들지 않았기 때문입니다.
⚠️ 비밀번호에 3가지 이상 문자 종류를 섞으세요.
Bill Burr는 p@ssw0rD#!2와 같이 복잡하게 섞어 사용하는 것을 바랐습니다. 하지만 사용자들은 역시 그의 생각과는 전혀 다르게 비밀번호를 구성했죠. Money-1, password!1 등과 같이 추론하기 쉬운 비밀번호를 만든 것입니다. 이는 보안 강화에는 전혀 효과가 없었고, 괜히 사용자의 부담만 높이는 셈이 되었습니다.
게다가 복잡해진 비밀번호를 외우지 못한 사용자가 메모장 등에 로그인 정보를 보관하게 되었고, 이를 탈취당하는 일까지 생겼습니다. 또한 가이드라인대로 만들어진 비밀번호는 기억하기 어렵기 때문에, 대부분의 사이트에서 모두 통일된 비밀번호를 사용하게 되고, 이 경우 한 곳이 해킹당하면 모두 해킹당하는 것과 마찬가지라는 단점도 가지게 되었습니다.
⚠️ 90일마다 비밀번호를 변경하세요.
45-90일마다 정기적으로 비밀번호를 바꾸는 것은 비밀번호를 바꾸지 않고 오랫동안 사용할 경우 유출이 되고, 해커의 무차별 대입 공격 가능성이 높다는 이유였습니다.
하지만 그 또한 크게 보안에 도움이 되지 않는다는 사실이 드러났습니다. 아래의 연구로 인해 알 수 있는데요.
노스 캘리포니아 대학교 연구진의 ‘비밀번호 만기일에 대한 보안연구’
1. 연구진은 3개월마다 비밀번호를 변경하도록 강제된 10,000개의 계정 정보를 확보했다.
2. 계정 이용자가 이전에 변경했던 비밀번호 이력 몇 개(약 4~15개)를 제공받았다. (연구진이 총 제공받은 비밀번호는 5만 1000여 개 정도)
3. 연구진은 비밀번호를 추측할 수 있는 ‘해독 도구’를 사용해 비밀번호를 알아내는 과정을 반복했다.
4. 수개월간 작업을 반복한 결과, 연구진은 약 60%의 비밀번호를 해독할 수 있었다.
연구진은 이용자가 3개월마다 변경한 비밀번호들에는 규칙이 있다고 설명했습니다. 새로운 비밀번호를 예전에 사용했던 비밀번호와 비슷하게 만든다는 것입니다. 연구진은 약 17% 계정은 5회 이하의 추측만으로도 비밀번호를 해독할 수 있었다고 말했습니다.
이로 인해 사용자는 비밀번호를 자주 변경하더라도 쉽게 예측될 수 있는 형태로 단순하게 조합하기에, 보안이 높은 비밀번호를 만드는 데 도움이 되지 않는다는 것을 알 수 있었습니다.
규칙에 부합하는 패스워드 생성 및 주기적으로 권고하는 기준에 따라 패스워드 변경 시
=> 사용자는 복잡한 생성 규칙에 기반하여 쉽게 예측될 수 있는 형태로 단순하게 조합 (예시: password1!, pw123!@# 등)
=> 사용자는 여러 계정의 패스워드를 파일에 저장,관리하는 등 또 다른 잠재적 위협을 유발
NIST에서는 생성 규칙의 복잡성을 높이거나 주기적 변경 요구를 금지했습니다. 생성하고 관리시 지켜야하는 요구사항이 과할 때, 사용자가 보안상 안전하지 않은 방식으로 처리할 가능성이 오히려 높다는 이유에서입니다. 즉, 원래 규칙이었던 세 가지 이상의 문자 조합과 90일마다 변경 요구 규칙이 삭제되었습니다.
대신 패스워드 생성 시 최소 8자 이상, 검증 시 연속 인증 시도 실패 시 횟수 제한 등의 사항을 권고하였습니다.
- 패스워드는 8자리 이상의 길이로 설정해야 한다.
- 가입자가 선택한 패스워드가 블랙리스트에 있을 때 다른 패스워드를 선택하도록 요구해야 한다.
- 검증자는 인증되지 않은 요청자가 접근할 수 있는 곳에 패스워드 유추 힌트를 절대 두면 안 된다.
- 패스워드를 고를 때 특정 정보 유형을 제시하면 안 된다. (당신의 첫 번째 강아지 이름은 무엇인가요?)
- 검증자는 가입자가 패스워드를 입력할 때 *나 -보다는 입력 값을 그대로 표시할 수 있는 옵션을 제공한다.
- 검증자는 패스워드에 대해 구성 규칙을 요구해서는 안 된다. (숫자, 대문자, 특수문자 혼합 등)
- 검증자는 패스워드를 임의로 변경하라고 요구하면 안 된다. (분기별 변경)
- 패스워드가 유출될 증거가 있을 때는 패스워드 변경을 강요해야한다.
- 연속실패에 대한 인증시도 횟수는 100회 이상으로 절대 하면 안 된다.
KISA(한국 인터넷 진흥원)에서도 비밀번호와 관련된 규칙을 개정 했습니다. 해당 링크에서 관련 자료를 확인하실 수 있습니다.
변경 내용은 아래와 같습니다.
세 종류 이상의 문자를 섞어서 8자리 이상의 패스워드를 만들어라.
=> (수정 후) 두 종류 이상의 문자를 섞어라. or 10자리 이상의 패스워드를 만들어라.
아직 풀리지 않은 하나의 의문
이제 왜 우리가 자주 마주하는 비밀번호 규칙들이 탄생하였고, 어떤 식으로 비밀번호 제약을 거는 게 권장하는 방식인지 알아보았습니다. 하지만 아직 풀리지 않은 의문이 있는데요. 바로 특수문자에 대한 의문입니다.
종종 회원가입 시 볼 수 있는 문구입니다.
사용 불가 특수 문자: ' " + / \ ; : - _ ^ ( ) < >
해당 특수 문자는 보안상 취약하므로 금지: < > ( ) # ' / |
이 특수문자들의 특징은... 사이트마다 다르다는 것입니다.
그리고 저희는 이런 문구를 볼 때마다 계속해 의문을 가지게 됩니다. "왜 어떤 곳에서는 @가 안 되고 어떤 곳에서는 #가 안 되는거야!"
결론만 말하자면, 이런 특수문자 제한은 필요 없습니다. 그리고 감히 말하자면 좋지 않습니다.
이런 제한은 저처럼 '왜'라는 의문을 불러오고, 더 나아가 사이트 보안에 대한 의심도 생기게 합니다. 비밀번호를 평문 그대로 저장하는 것도 아닌데 왜 일부 문자가 제한되지?라는 물음이 생기는 것은 어쩌면 당연합니다.
물론 저런 사이트들이 잘못되었다는 것은 아닙니다. 시스템 상에서 어쩔 수 없었을 수도 있고, 아직 옛날 웹 문법을 사용중이거나 등 나름의 사정이 있었을 테니까요. 하지만 그런 사정이 있는 게 아니라면 이런 제한은 굳이 둘 필요가 없습니다. 💨
2) 🔐 특수문자를 쓰면 보안에 더 도움이 될까?
NIST에서 특수문자 포함 규칙을 삭제했지만, 그렇다고 해서 특수문자가 보안에 도움이 되지 않는 것은 아닙니다.
- 특수문자를 쓰게 하면 해커가 추측이 어려운 비밀번호가 만들어지겠지.
- 어라 사람들이 그래도 예측하기 쉬운 비밀번호를 만드네. 그리고 불편해 한다.
- 어라 어딘가에 비밀번호를 써놓고 그걸 탈취당하기도 하네.
- 이럴바엔 규칙을 삭제하자.
이렇게 된 것이지, 특수문자를 사용하면 보안에 도움이 되는 것은 맞습니다. 실제로 해킹 방법 중 무차별 대입 방식이 있는데, 특수문자가 들어가게 되면 경우의 수가 많이 늘어나게 됩니다. 비밀번호 안전 여부를 체크하는 사이트에서도 문자 뒤에 특수문자만 넣어주면 (비번 해킹 시간이) 하루에서 4년으로 늘어나기도 합니다. (해당 사이트가 얼마나 신빙성 있는지는 모르겠습니다.)
그렇다면 대체 안전한 비밀번호는 어떻게 만들어야 할까?
사용자 관점에서 보자면, 말도 안 되는 긴 비밀번호가 가장 안전하다고 합니다. FBI(미국 연방수사국)은 Passphrase(패스프레이즈)를 사용하는 것을 추천했습니다. Passphrase는 여러 단어를 섞어 만든 비밀번호를 말하는데, DirectorMonthLearnTruck같이 어울리지 않은 여러 단어를 섞은 것입니다.
FBI는 짧고 어려운 비밀번호보다 15자 이상의 긴 비밀번호가 해독하기 더 어렵다고 하며, 복잡성보다 길이가 더 중요하다고 강조하였습니다. (NIST 역시 비밀번호 길이가 길수록 암호를 푸는데 더 노력을 기울어야 한다고 말했습니다.)
FBI는 "복잡하지만 짧은 비밀번호는 기억하기만 힘들다"며 "대신 긴 비밀번호를 사용하는 것이 좋다"고 하였습니다.🤭
이어서 "최소 15자 이상의 복수 단어들로 조합해야 한다"며 "추가된 패스프레이즈 부분으로 인해 해커들이 알아내기는 어렵지만 계정 주인이 기억하기는 더 쉬워진다"고 덧붙였습니다.
이는 비밀번호가 컴퓨터에서 암호화 돼 2진법으로 바뀌면, 비밀번호 문자열이 긴 것만으로도 조합의 가지 수는 대폭 늘어나게 되기 때문입니다. 비밀번호에 포함된 특수문자 등도 복잡도를 높이는데 기여할 수 있으나, 해커 입장에서는 긴 비밀번호를 푸는데 더 많은 노력을 필요로 하기 때문에 더 안전하다는 것이죠.
결론: 긴 비밀번호 > 짧고 복잡한 비밀번호 ‼️‼️
제 첫 고민의 시발점이었던 "비밀번호에 특정 특수문자 제한을 둬야하나?"는 아니요~로 판명 났습니다.
그럼 다른 제한은 둬야할까요?
개인적인 결론은 굳이 둬야하나... 입니다. 글자 수 제한만 필수로 두고, 어떤 비밀번호를 권장하는지와 함께 어떻게 해야 안전한지에 대한 내용을 추가 제공하는 게 가장 이상적인 방향이라는 생각입니다.
그래서 결론을 말하자면, 최소한의 규칙을 지키는 선에서는 서비스 제공자의 마음인 것 같습니다.
그러나 너무 단순한 비밀번호는 블랙 리스트로 저장해서 막는 게 좋다고 생각하긴 합니다. (NIST 권고 사항에도 있듯이)
마무리하며
회원가입을 하며 한 번쯤 궁금해하셨을 비밀번호 규칙에 대해 정리해보았는데, 해당 글로 궁금증이 해소가 되셨으면 좋겠습니다. ㅎㅎ
혹시 잘못된 정보가 있거나 아쉬운 부분이 있다면 댓글 남겨주시면 감사하겠습니다.
그럼 오늘도 좋은 하루 보내세요!
참고 자료
개인 정보 보호 위원회 - 개인정보의 기술적, 관리적 보호조치
금융보안원 - 미 국립 표준기술 연구소, 패스워드 관리에 대한 권고사항
올바른 패스워드 작성 규칙 (이 분 글을 거의 마지막에 읽었는데, 간단히 잘 설명해주신 것 같습니다.)
'Etc' 카테고리의 다른 글
| [디자인 패턴] Gof의 디자인 패턴이란? (0) | 2025.04.10 |
|---|---|
| 엑셀 읽어오기 API 개발 시 꼭 고려해야하는 상황 및 예외처리 w 토지조서 엑셀, Apache POI 타입, 엑셀 서식 문제 (0) | 2025.03.02 |
| 왜 우리는 CORS를 알아야 할까? (3) | 2024.11.09 |