NIST의 비밀번호 권고 변경

요즘 암호학적 안전은 계산의 복잡성을 전제로 하면서 점점 '사회공학적(social engineering)' 측면을 더욱 세심하게 고려하고 있습니다. 그리고 암호 규칙은 사람들의 관습에서 관찰되는 패턴에 따라 규칙이 역전되거나 더욱 정교한 방향을 찾고 있죠.

1. 비밀번호 길이가 거의 모든 이슈의 중심입니다.

비밀번호는 규칙의 복잡성(ex: 특수문자를 반드시 포함, 대문자를 반드시 포함 등)보다 비밀번호 길이가 중요합니다. 특수문자가 포함될 수 있다는 것이 암호학적 계산의 복잡성은 높여 주지만, 어차피 사용자가 특수문자를 사용하는 위치와 개수 등이 대체로 비슷하기 때문에 효과적이지 않았습니다. 이는 오랫동안 꾸준히 언급되고 있습니다.

비밀번호의 최소 길이에서 권장 길이는 다음과 같습니다.

사용자가 생성하는 비밀번호: 최소 8글자 이상
기계 생성 비밀번호: 최소 6글자 이상 (ex: OTP 등)

2. 64글자 비밀번호를 사용할 수 있도록 허용합니다.

즉, 비밀번호에서 최대 길이에서 권장 길이는 64 또는 그 이상으로 설정하는 것이 좋습니다. 예를 들어, 구글은 100글자까지 입력할 수 있도록 허용합니다.

64글자나 그 이상의 긴 비밀번호는 쉽게 유출되지 않고 고유한 문구를 사용할 수 있기 때문에 기억하기 쉽습니다.

64글자 고유한 문구 예시 (영문으로 작성하는 64글자 예시)

"불닭볶음면잘됐으면좋겠다맛있는데군대에서도먹었"
"더맥락없는문장으로쓰면안전한비밀번호가된다고하던"

사용자는 보안성보다 사용성에 초점을 두는 비밀번호 습관을 보여 주는데, 길고 고유한 문구를 사용하는 비밀번호는 보안성과 사용성을 함께 갖출 수 있어 사용자에게 안전한 비밀번호를 유도합니다.

3. 비밀번호 블랙리스트를 확인하세요.

비밀번호를 만들 때는 다음 목록에 해당하지 않아야겠죠.
(위험도가 높으면 차단, 아니면 경고)

유출이 확인된 적이 있는 비밀번호
사전 공격에 등록된 단어
(사람들이 자주 사용하는 비밀번호나 그와 닮은 문자 조합, 사용자의 개인 정보 등이 주요 대상)
반복적이거나 순차적인 문자(ex: "aaaaa", "1234abcd")
유추되는 문맥(ex: 서비스 이름, 사용자 계정명, 많이 노출된 개인정보 등)

여기 사용자의 비밀번호를 유추하기 좋은 '유출 비밀번호 목록'이 있습니다.

Leaked Password Databases:
https://github.com/danielmiessler/SecLists/tree/master/Passwords/Leaked-Databases

비밀번호가 길더라도 반복되고 강조되는 문자로만 되어 있다면 쉽게 유추될 수도 있으니, 비밀번호 길이 안전성을 계산할 때는 반복되는 토큰을 추려낸 다음 고려하는 게 좋아 보입니다.

4. 특수문자를 강요하지 마세요.

(단, 입력은 할 수 있게 합니다.)

사용자에게 특수문자를 포함하도록 강요하는 것은, 오히려 사용자에게 쉬운 암호 패턴을 유도한다고 보입니다. 사용자는 어차피 비밀번호에 한두 글자의 특수문자만 포함하고 그 위치도 유추하기 쉬우며, 기억하는 부담을 줄이기 위해 오히려 취약한 비밀번호를 생성할 가능성을 높일 수 있습니다.

NIST는 비밀번호에 대문자나 특수문자를 포함하도록 하면, 사용자가 오히려 취약한 비밀번호를 생성할 가능성을 높인다고 주장합니다. 특수문자를 포함하는 규칙은 사용자의 비밀번호 생성 패턴에서 생각보다 강력하지 않았다고 분석되었거든요. 어쩌면 여러분도 한두 글자만 포함하고 계실지도 모릅니다.

따라서 특수문자, 대문자 등의 규칙을 필수 정책으로 하기보다, 선택사항으로 하자는 겁니다.

또 한 가지 중요한 것은, 이것이 사용자가 특수문자를 사용할 수 없도록 하자는 취지는 아니라는 겁니다. 사용자가 애착 문자^❤️를 하나 정해서 사이트마다 요구사항에 따라서만 조금씩 바꾸고 돌려 쓰는 방식은 별로지만, 특수문자를 다양하게 포함해서 경우의 수를 늘리는 방식은 여전히 좋은 방식입니다. 비밀번호 관리 도구를 사용할 때도 유용할 수 있죠.

5. 비밀번호에 대한 피드백을 제공합시다.

사용자 비밀번호를 강도 높은 수준으로 다룰 수 있도록 유도할 수 있습니다. 일반적으로는 이런 방법들이 도움이 될 거예요.

비밀번호 세기 측정기를 구현합니다.
(password-strength meters)
비밀번호 시도 횟수를 제한합니다.
작성 중인 비밀번호를 볼 수 있는 UI를 제공합니다.
(예를 들어 눈 모양 아이콘을 눌러 마스킹되지 않은 비밀번호를 확인할 수 있도록 합니다.)

사용자가 기준에 맞지 않는 비밀번호를 만들려고 하면, 어떤 규칙을 위반하는지 설명해 주어야 합니다.

6. 비밀번호 찾기 힌트를 제공하지 않습니다.

"어릴 적 추억의 장소는?", "나의 초등학교 이름은?"

저처럼 젊은 세대에게는 낯선 표현이지만, 어른들 세대에는 이것이 충분히 안전한 방식으로 좋은 사용자 경험을 제공한다고 생각한 것 같습니다.

하지만 이 힌트가 사용자 본인에게만 힌트인 것은 아닙니다. 사용자 계정에 무단으로 로그인을 시도하는 사람에게도 힌트를 주겠죠.

따라서 비밀번호 분실 시 힌트를 제공하는 것보다, 이메일, 전화번호, 또는 본인확인서비스 등 대체 인증 수단으로 신원을 확인해서 비밀번호 재설정을 하는 방식이 보안에 좋습니다.

(이런 비밀번호 규칙은 주로 온라인 서비스를 대상으로 합니다. 오프라인 단말기 암호 등은 다른 이유로 힌트가 필요할 수 있습니다.)

7. 패스워드 매니저를 안전하게 사용하세요.

많은 사람들이 비밀번호 관리 도구(패스워드 매니저)를 사용하고 있습니다. NIST에서 패스워드 매니저 사용을 명시적으로 권장하는 것은 아니지만, 계정 관리자가 비밀번호 관리 프로그램을 사용할 수 있도록 복사하여 붙여넣기 기능을 허용하자고 안내하고 있습니다. (직원들에게 허용하도록)

NIST는 비밀번호 관리자 사용에 대해 다음과 같은 권장 사항을 제시했습니다.

외울 수 있는 긴 비밀번호 문구를 선택하세요.
패스워드 매니저에서 모든 계정에 대해 고유한 비밀번호를 만드세요.
마스터 비밀번호의 복구를 허용하는 패스워드 매니저는 피하세요.
패스워드 매니저에 MFA(다중 인증. 주로 OTP 등)를 사용하세요.
온라인 보안 질문에 대해 무작위로 복잡한 답변을 생성하세요.

8. 비밀번호는 필요할 때만 바꾸도록 합니다.

우리나라는 아직 개인정보 취급자 계정(직원용 계정)의 비밀번호를 6개월마다 반드시 바꾸도록 하지만, 이제 그것이 보안을 강화하기보다 오히려 동일하거나 비슷한 비밀번호를 다시 사용하는 습관을 부추기는 것을 알게 되었습니다.

이제 NIST는 비밀번호를 변경해야 하는 경우를 다음 두 가지로 이야기합니다.

인증 기관에 대한 해킹이 발견되었을 때
사용자가 그냥 원할 때

9. 오프라인 공격 저항성을 보장하면서 비밀번호를 저장합니다.

데이터베이스 등에 있는 비밀번호 해시 값은 생각보다 자주 유출되어 왔습니다. 해시 값이 유출되고 나면 더 이상 운영 중인 서버에 브루트포스 등을 시도할 필요가 없습니다. 컴퓨터에 환경을 구축해서 오프라인 상태로 비밀번호를 찍어 볼 수 있거든요.

이것을 방지하기 위해서, 동시에 여러 비밀번호를 암호화하기 버겁도록 적절한 KDF(키 유도 함수. Key Derivation Function)를 사용하여 비밀번호를 솔팅 및 해싱 하도록 권장합니다.

'단방향 암호화'는 원래 필수이고, 이때 알맞은 암호화 함수를 사용하는 것을 권장하는 것입니다.

비밀번호 해시 값 유출 사례

개인정보 유출 사례 중 단방향 암호화된 비밀번호를 포함하는 사례는 많이 있습니다. 대부분 기본적으로 단방향 암호화를 해 둔 상태였으며, 이때 유출되는 정보로는 비밀번호를 도출하거나, 그 사이트에서 사용 가능한 대체 비밀번호를 만드는 데에 상당한 시간이 필요합니다.

2008 | 옥션 | 1081만 명 → 1863만 명 | 비밀번호 포함
2010 | 25개 업체(신세계 등) | 2000만 건 | 일부는 비밀번호 포함
2011 | 네이트-싸이월드 | 3500만 명 | 비밀번호 포함
2011 | 넥슨 | 1320만 명 | 비밀번호 포함
2013 | 어도비 | 290만 명 → 3800만 명 | 비밀번호 포함
2014 | 네이버 | 20만 명 | 비밀번호 포함
2014 | 티몬 | 113만 명 | 비밀번호 포함
2014(2011. 06 발생 짐작) | 천재교육 | 규모 모름(350만 명 이하) | 비밀번호 포함
2014 | 스킨푸드 | 55만 명 | 비밀번호 포함
2014 | 토니모리 | 50만 명 | 비밀번호 포함
2014 | 이베이 | 최대 1억 4500만 명 | 비밀번호 포함
2014 | 아프리카TV | 규모 안 밝힘 | 비밀번호 포함
2014 | 능률교육 | 1,048,576 건 | 비밀번호 포함
2015 | 뽐뿌 | 190만 명 | 비밀번호 포함
| 심각(MD5)
2016(2012 발생) | 링크드인 | 1억 6700만 건 | 비밀번호 포함
2016 | 링크드인 | 1억 1700만 명 | 비밀번호 포함 (위와 별건)
2016 | 인터파크 | 1030만 명(2540만 건) | DB 유출
2017 | 이스트소프트 | 13만 3800여 건 | 비밀번호 포함
2017(2013 발생) | 야후 | 10억 명 → 30억 명 | 비밀번호 포함
| 심각(MD5)
2018 | 윈윈소프트 | 규모 안 밝힘 | DB 해킹, 비밀번호 포함
2019 | 스카이에듀 | 규모 안 밝힘 | 비밀번호 여부는 모호하게 표현
2019 | 메가스터디 | 570만 명 | 비밀번호 포함
2019 | 슈프리마
| 2780만 건 | 지문, 안면데이터 등이 암호화되지 않은 채 노출됨 (유출 여부 모름)
| 심각(생체정보 평문)
2020 | 국내 여러 카드 및 멤버십 가맹점, 은행 등
| 단순계산 시 누적 412억 건 정도(1.5테라바이트) | 카드 번호, 카드 유효기간, 카드 비밀번호 포함
2020 | 위더스교육 | 비밀번호 포함
2021 | 밀크T(천재교육) | 비밀번호 여부는 모호하게 표현
2022 | 발란 | 비밀번호 여부는 모호하게 표현
2023 | LG U+ | 29만 명 → 59만 명 | 비밀번호 포함
2023 | 더쿠 | 규모 안 밝힘 | 비밀번호 포함

외부에서 암호가 유출되었을 가능성이 있는 사례

2023 | 한국장학재단 | 규모 안 밝힘 | 해외 IP의 대규모 로그인 시도
2023 | 워크넷(한국고용정보원)
| 로그인 시도 500만여 건 중 38만여 건이 성공(23만 명 유출) | 해외 IP의 대규모 로그인 시도

기타

Q. 비밀번호 힌트를 제공하는 Microsoft?

"아직도 비밀번호 힌트를 사용하세요? 그런 건 마이크로소프트나 하는 건데요."

비밀번호 힌트가 더 이상 추천되지 않는데도 불구하고, 많은 단말기의 운영체제가 사용자 계정에 대해 '비밀번호 힌트'를 제공합니다. 사실 이는 보안보다는 사용자 경험에 균형을 맞추기 위한 것이고, 다음 이유로 비교적 합리적인 결정일 수 있죠.

오프라인 환경

개인용 기기에서 사용되는 경우가 많아 온라인 공격에 노출될 가능성이 상대적으로 낮습니다.

능숙하지 않은 사용자

특히 고령자나 기술적으로 덜 숙련된 사용자에게는 비밀번호 힌트가 필요한 수단일 수 있습니다.

접근·사용 빈도가 낮은 기기나 계정

사용 빈도가 낮고 중요도가 낮은 계정이라면, 복잡한 분실 복구보다 비밀번호 힌트가 합리적으로 보일 수 있습니다.

비밀번호 분실 시 초기화할 수 없는 사용자도 존재

어떤 사용자는 기술적으로 사소한 일을 하는 데에도 어려움을 겪을 수 있습니다. 또는 대체 인증 수단이 없어서 이메일이나 전화번호 인증을 통한 복구도 안 될 수도 있습니다. 예를 들어 계정을 만들 때 등록한 이메일, 전화 번호를 더 이상 사용하지 않을 수도 있죠.

그럼에도 급한 용무로 기기를 사용해야 할 수도 있는 사용자를 위해서 비밀번호를 떠올릴 수단을 제공할 수 있습니다.

References

NIST의 패스워드 가이드라인을 해석하여 정리

https://www.itsasap.com/blog/nist-password-guidelines
유출된 비밀번호들
https://github.com/danielmiessler/SecLists/tree/master/Passwords/Leaked-Databases
비밀번호 해시 값 유출 사례
1. 목록 확인 (나무위키 "개인정보 유출 사태")
  
  https://namu.wiki/w/%EA%B0%9C%EC%9D%B8%20%EC%A0%95%EB%B3%B4%20%EC%9C%A0%EC%B6%9C%20%EC%82%AC%ED%83%9C
2. 규모와 암호화된 비밀번호 유출 여부 등은 각각 기사를 찾아 보며 기록했습니다.

비밀번호 생성 규칙: 서비스의 정책 결정 (NIST 비밀번호 가이드라인 2024) NIST Password Guidelines

Table of contents