Why can only write certain special characters in passwords.md

회원가입을 하는데, 비밀번호에는 !@&^만 사용할 수 있다는 문구가 떴다. 옛날에는 그냥 그렇구나 싶었을 것이다. 그런데 의문이 들었다.

왜?

따지는 의문은 아니었다. 그게 더 안전한가? 다른 비밀번호는 무슨 오류가 발생하나? 그럼 굳이 제한을 두고 있지 않은 내 회원가입 API는 좋지 않은 API인가? 에서 오는 왜였다.

의문은 의문을 불러왔다. 비밀번호 글자수 제한이 있는 사이트부터 꼭 특수문자가 들어가야 하는 사이트, 대문자 특수문자 소문자가 모두 들어가야 하는 사이트. 뭐가 맞는걸까? 그러니까, 어떤 비밀번호가 안전할까? 나는 회원가입 API를 만들 때 어떤 제약을 거는 게 좋지?

개인 정보 보호 위원회에서는

여기 개인 정보의 기술적 관리적 보호조치 기준 제 4조가 있다.

여기서 우리가 봐야할 건 8항의 1번 2번이다.

• 영문, 숫자, 특수문자 중 2종류 이상을 조합하여 최소 10자리 이상.
• 또는 3종류 이상을 조합하여 최소 8자리 이상.

영문, 숫자, 특수문자를 포함하고 90일 주기로 비밀번호 변경이라는 규칙은 우리가 아마 가장 많이보고 보편적인, 그런 규칙일 것이다.

그럼 이런 규칙들은 왜, 어디에서 나오게 되었을까?

이런 규칙들은...

NIST에서 2003년 발표한 Digital Identity Guidelines의 내용 중 일부이다. 미국을 비롯한 세계 각국에서도 이 가이드라인을 따르며, 하나의 보편적인 규칙으로 떠올랐다. ✈

"해킹당하고싶지 않으면 대문자, 소문자, 숫자, 특수문자를 써서 패스워드를 만들어라."

이런 내용을 담은 사람은 Bill Burr(빌 버), Tim Polk(팀 포크), Donna Dods(도나 도즈)이다.

😮 그러나

규칙을 만든 Bill Burr가 2017년 WSJ 인터뷰에서 이런 규칙이 비밀번호 보안 수준을 높이는 데 별 도움이 되지 않는다고 밝혔다. 많은 이들의 불편과 시간 낭비를 유발했다면서 '내가 했던 일을 후회한다'며 사과하였다.

2021년 NIST는 가이드라인이 오히려 보안에 취약할 수 있다는 사실을 인정하고, 이에 개정된 보고서를 공개했다. 개정 작업을 맡은 NIST 표준 및 기술 고문 Paul Grassi(폴 그라시)는 특수문자 입력이나 만료기간같은 조건이 별로 도움이 안 됐다며, 실제로 사용성에 부정적인 영향을 줬다고 말하기도 했다.

Whyyyyyy? 😲

왜 Bill Burr는 후회하고, 2004년의 가이드라인은 오히려 보안에 취약점을 줄까? 그저 단지 옛날에 만든 규칙이었어서?

아니다. 바로 이용자들의 성향을 고려해 규칙을 만들지 않았기 때문이다.

⚠ 비밀번호에 3가지 이상 문자 종류를 섞으세요.

Bill 씨는 p@ssw0rD#!2와 같이 복잡하게 섞어 사용하는 걸 바랐지만, 사용자들은 그의 생각과는 다르게 비밀번호를 구성했다. Monkey-1, password1!등과 같이 추론하기 쉬운 비밀번호를 만든 것이다. 보안 강화에는 전혀 효과가 없었고, 괜히 사용자의 부담만 높이는 셈이 되었다.

게다가 비밀번호를 외우지 못하는 사용자가 메모장이나 다른 형태에 로그인 정보를 보관하게 되었고, 이를 탈취당하는 일까지 생겼다. 또는 이 가이드라인대로 비밀번호를 만들면 기억이 어렵기 때문에 대부분의 사이트에서 모두 통일된 비밀번호를 사용하게 되는데, 이럴 경우 한 곳이 해킹당하면 모두 해킹당하는 것과 마찬가지라는 단점도 가지게 되었다.

⚠ 90일마다 비밀번호를 변경하세요.

45-90일마다 정기적으로 비밀번호를 바꾸는 것은 비밀번호를 바꾸지 않고 오랫동안 사용할 경우 유출, 해커의 무차별 대입 공격 가능성이 높다는 게 이유였다.

밑에 실제 관련 연구가 있다. (노스 캘리포니아 대학교 연구진은 ‘비밀번호 만기일에 대한 보안연구’)

1. 연구진은 3개월마다 비밀번호를 변경하도록 강제된 10,000개의 계정 정보를 확보했다.

2. 계정 이용자가 이전에 변경했던 비밀번호 이력 몇 개(약 4~15개)를 제공받았다. (연구진이 총 제공받은 비밀번호는 5만 1000여 개 정도)

3. 연구진은 비밀번호를 추측할 수 있는 ‘해독 도구’를 사용해 비밀번호를 알아내는 과정을 반복했다.

4. 수개월간 작업을 반복한 결과, 연구진은 약 60%의 비밀번호를 해독할 수 있었다.

연구진은 변경된 비밀번호에 규칙이 있다고 설명했다. 새로운 비밀번호를 예전에 사용했던 비밀번호와 비슷하게 만든다는 것이다. 연구진은 약 17% 계정은 5회 이하 추측으로 비밀번호를 해독할 수 있었다고 말했다.

이로 인해 사용자는 비밀번호를 자주 변경하더라도 쉽게 예측될 수 있는 형태로 단순하게 조합하고, 보안이 높은 비밀번호를 만드는 데 도움이 되지 않는다는 것을 일 수 있다.

규칙에 부합하는 패스워드 생성 및 주기적으로 권고하는 기준에 따라 패스워드 변경 시

=> 사용자는 복잡한 생성 규칙에 기반하여 쉽게 예측될 수 있는 형태로 단순하게 조합 (예시: password1!, pw123!@# 등)

=> 사용자는 여러 계정의 패스워드를 파일에 저장,관리하는 등 또 다른 잠재적 위협을 유발

그래서 현재 NIST에서는

NIST에서는 생성 규칙의 복잡성을 높이거나 주기적 변경 요구를 금지했다. 생성하고 관리시 지켜야하는 요구사항이 과할 때, 사용자가 보안상 안전하지 않은 방식으로 처리할 가능성이 오히려 높다는 이유에서이다. 즉, 원래 규칙이었던 세 가지 이상의 문자 조합과 90일마다 변경 요구 규칙이 삭제되었음을 뜻한다.

대신 패스워드 생성 시 최소 8자 이상, 검증 시 연속 인증 시도 실패 시 횟수 제한 등의 사항을 권고했다. 개인적으로 도움이 된 권고 사항은 공격당하기 쉬운 패스워드를 블랙리스트에 포함시키는 것이다.

✔ 필수

• 패스워드는 8자리 이상의 길이로 설정해야 한다.

• 가입자가 선택한 패스워드가 블랙리스트에 있을 때 다른 패스워드를 선택하도록 요구해야 한다.

• 검증자는 인증되지 않은 요청자가 접근할 수 있는 곳에 패스워드 유추 힌트를 절대 두면 안 된다.

• 패스워드를 고를 때 특정 정보 유형을 제시하면 안 된다. (당신의 첫 번째 강아지 이름은 무엇인가요?)

• 검증자는 가입자가 패스워드를 입력할 때 *나 -보다는 입력 값을 그대로 표시할 수 있는 옵션을 제공한다.

• 검증자는 패스워드에 대해 구성 규칙을 요구해서는 안 된다. (숫자, 대문자, 특수문자 혼합 등)

• 검증자는 패스워드를 임의로 변경하라고 요구하면 안 된다. (분기별 변경)

• 패스워드가 유출될 증거가 있을 때는 패스워드 변경을 강요해야한다.

• 연속실패에 대한 인증시도 횟수는 100회 이상으로 절대 하면 안 된다.

그리고 KISA에서도

KISA에서도 비밀번호와 관련된 규칙을 업데이트 했다. KISA는 한국 인터넷 진흥원이고, 여기서 자료를 확인할 수 있다.

변경 내용은 이와 같다.

세 종류 이상의 문자를 섞어서 8자리 이상의 패스워드를 만들어라.

=> (수정 후) 두 종류 이상의 문자를 섞어라. or 10자리 이상의 패스워드를 만들어라.

나의 의문

🤐 특수문자 제한, 필요한가?

종종 회원가입 시 볼 수 있는 문구이다.

사용 불가 특수 문자: ' " + / \ ; : - _ ^ ( ) < >

아래 특수 문자는 보안상 취약하므로 금지: < > ( ) # ' / |

이의 특징은 사이트마다 다르다는 것이다.

어떤 사이트는 *|가 사용 불가라고 나와있는 반면, 다른 사이트는 *|가 사용 가능하다고 나와있기도 하다. 사용자들은 이때문에 불편함을 많이 느끼게 된다.

통일 비번 쓰는데 어디서는 @가 안되고 어디서는 #가 안되고...

• 물론 통일 비번의 위험성은 어디서든 알려져있다.

결론을 말하자면 필요 없다. 그리고 감히 말하자면 좋지 않다. 일단 사용자에게 의문을 불러온다. 😵 이 글을 작성하기 위해 많은 글을 찾아봤는데, 모두 나와 같은 의문을 가지고 있었다.

Whyyyyyy?

그리고 그렇게 물어보는 사람들에게 제대로 된 답변은 단 한가지도 돌아오지 않았다. 그들은 더 나아가 사이트 보안에 대한 의심도 하게 된다. 비밀번호를 평문 그대로 저장하나? 왜 저러지? 라는 말이 나오는 것도 많이 볼 수 있었다.

저런 사이트가 모두 잘못됐다는 것은 아니다. 시스템 상에서 어쩔 수 없었을 수도 있고, 나름의 사정이 있었을테니 말이다. 하지만 그런 게 아니라면 이런 제한은 굳이 둘 필요가 없다. 💨

🔐 특수문자를 쓰면 보안이 더 잘 될까?

NIST에서 특수문자 포함 규칙을 삭제했다고 해서 특수문자가 보안에 도움이 되지 않는 것은 아니다. 2007년의 가이드라인 의도는 J!K@Q#7542^같이 특수문자를 통해 복잡하고 예측 불가능한 비밀번호였다. 이토록 해커가 비밀번호를 추측하기 어렵게 하기 위해 만든 규칙인데, 사람들은 생각과는 다르게 비밀번호를 구성했다. 'Monkey-1'과 같이 추론하기 쉬운 비밀번호를 만들었고, 이는 보안 강화에 아무런 효과도 주지 못했다. 괜히 사용자의 부담만 높이는 셈이 되어버린 것이다. 게다가 비밀번호를 외우지 못하는 사용자가 메모장 등에 로그인 정보를 보관하게 됐고 이를 탈취당하는 일까지 생겨버려, 이는 도움이 되지 않는다라고 판단내리고 규칙을 삭제한 것이다.

1. 특수문자를 쓰게 하면 해커가 추측이 어려운 비밀번호가 만들어지겠지.
2. 어라 사람들이 그래도 예측하기 쉬운 비밀번호를 만드네. 그리고 불편해 한다.
3. 어라 어딘가에 비밀번호를 써놓고 그걸 탈취당하기도 하네.
4. 이럴바엔 규칙을 삭제하자.

특수문자를 쓰면 보안에 도움이 되긴한다. 그런데 특수문자를 맹신해 다른 문자를 쉽게 쓰는 것은 오히려 마이너스를 불러온다는 것이다. 해킹방법 중 무차별 대입 방식이 있는데 특수기호가 들어가면 경우의 수가 많이 늘어나기때문이다.

실제로 비밀번호 안전 여부를 체크하는 사이트에서 문자 뒤에 특수문자만 넣어주면 (비번 해킹 시간이) 하루에서 4년으로 늘어나기도 한다. (얼마나 신빙성 있는지는 모르겠음)

특수문자, 소문자, 대문자 세 가지를 섞어야 할까(세 가지 이상의 문자 종류를 섞어야 할까)라는 의문도 이와 비슷하게 답할 수 있을것같다.

숫자, 특수문자가 포함되지 않은 긴 단어(문장)가 숫자, 영문, 특수문자의 조합보다 더욱 안전하다는 것은 사실이다. 그러나 숫자, 영문, 특수문자가 들어가게 되면 더욱 더 안전해질것이다.

그렇다면 대체 안전한 비밀번호는 어떻게 만들어야 할까?

사용자 관점에서 보자면, 말도 안 되는 긴 비밀번호가 가장 안전하다고 한다. FBI(미국 연방수사국)은 Passphrase(패스프레이즈)를 사용하는 것을 추천했다. Passphrase는 여러 단어를 섞어 만든 비밀번호를 말한다. DirectorMonthLearnTruck같이 어울리지 않은 여러 단어를 섞은 것이 더 낫다는 것이다. FBI는 복잡성보다 길이가 더 중요하다고 강조했다. 짧고 어려운 비밀번호보다 15자 이상의 긴 비밀번호가 해독하기 더 어렵다고 했다. (NIST 역시 비밀번호 길이가 길수록 암호를 푸는데 더 노력을 기울어야 한다고 말했다.)

FBI는 "복잡하지만 짧은 비밀번호는 기억하기만 힘들다"며 "대신 긴 비밀번호를 사용하는 것이 좋다"고 밝혔다.

이어 "최소 15자 이상의 복수 단어들로 조합해야 한다"며 "추가된 패스프레이즈 부분으로 인해 해커들이 알아내기는 어렵지만 계정 주인이 기억하기는 더 쉬워진다"고 덧붙였다.

비밀번호가 컴퓨터에서 암호화 돼 0과 1의 2진법으로 바뀌면, 비밀번호 문자열이 긴 것만으로도 조합의 가지 수는 대폭 늘어난다. 비밀번호에 포함된 특수문자 등이 복잡도를 높이는데 기여할 수 있으나, 해커 입장에서는 긴 비밀번호를 푸는데 더 많은 컴퓨터 역량을 필요로 한다.

긴 비밀번호 > 짧고 복잡한 비밀번호

그럼 개발자는?

내 고민의 첫 시발점이었던 특수문자 제한을 둬야하나? 는 아니요~로 판명났다. 그럼 다른 제한은? 개인적인 결론은 굳이 둬야하나... 이다. 다음에 서비스를 만들 때는 글자 수 제한만 두는 게 좋을 것 같다. (10자 이상) 특수 문자를 추가한다고 보안이 강화되는 게 아니라면, 굳이 강제할 필요가 없다고 생각되기 때문이다. 어떤 비밀번호를 권장하는지, 어떻게 해야 안전한지에 대한 내용을 띄워주면 좋을 것 같다는 생각도 들었다.

그래서 결론을 말하자면 개발자 나름이다. 어떤 지침을 따를 것인지, 어떤 생각을 가지고 있는지가 다 다르기때문에 '이게 옳아.'라고 말할 수는 없을 것 같다.

그러나, 너무 단순한 비밀번호는 블랙 리스트로 저장해서 막는 게 좋다고 생각된다. (ex 1234567, abcdefg....)

참고 자료

개인 정보 보호 위원회 - 개인정보의 기술적, 관리적 보호조치

금융보안원 - 미 국립 표준기술 연구소, 패스워드 관리에 대한 권고사항

비밀번호에 사용되는 특수문자, 사실은 의미 없다?

IBM - 비밀번호 보안 수준 규칙

올바른 패스워드 작성 규칙 (이 분 글을 거의 마지막에 읽었는데, 꽤나 간단히 잘 설명해주신 것 같다.)

NAVER - 안전한 비밀번호 만드는 방법