GN⁺: NIST(미국 국립표준기술연구소), 특정 비밀번호 문자 구성 요구 금지
(mastodon.social)- NIST는 "다양한 문자 스타일로 구성된 비밀번호 작성 요구 사항"과 "주기적인 비밀번호 변경 요구 사항"을 "금지"할 예정. 이는 사이버 보안 약점으로 간주됨
비밀번호 요구사항
- 검증자와 CSP는 비밀번호의 길이가 최소 8자 이상이어야 하며, 최소 15자 이상이 되도록 요구하는 것이 좋음 SHALL
- 검증자와 CSP는 최대 비밀번호 길이를 최소 64자 이상 허용하는 것이 좋음 SHOULD
- 검증자와 CSP는 비밀번호에 모든 ASCII 인쇄 가능 문자와 공백 문자를 허용하는 것이 좋음 SHOULD
- 검증자와 CSP는 비밀번호에 Unicode 문자를 허용하는 것이 좋음. 비밀번호 길이를 평가할 때 각 Unicode 코드 포인트는 단일 문자로 계산되어야 함 SHOULD
- 검증자와 CSP는 비밀번호에 대해 다른 구성 규칙(예: 다양한 문자 유형의 혼합 요구)을 부과해서는 안 됨 SHALL NOT
- 검증자와 CSP는 사용자에게 주기적으로 비밀번호를 변경하도록 요구해서는 안 됨. SHALL NOT 그러나 인증자의 침해 증거가 있는 경우 검증자는 변경을 강제해야 함 SHALL
- 검증자와 CSP는 가입자가 인증되지 않은 청구인이 액세스할 수 있는 힌트를 저장하도록 허용해서는 안 됨 SHALL NOT
- 검증자와 CSP는 비밀번호를 선택할 때 가입자에게 지식 기반 인증(KBA) 또는 보안 질문을 사용하도록 프롬프트해서는 안 됨 SHALL NOT
- 검증자는 제출된 비밀번호 전체를 검증해야 함(즉, 잘라내지 않아야 함) SHALL
다른 멘션들
- 기존 규칙의 문제점: 이전에는 유니코드 문자가 특정 플랫폼에서 제대로 저장되지 않는 문제가 있었음. 하지만 현재는 유니코드가 더 많은 엔트로피를 제공함
- 새로운 요구 사항: 새로운 NIST 가이드라인에서는 임의의 유니코드 허용 요구 사항이 포함될 예정. 이는 국제화(i18n)를 주장하는 소프트웨어에 필수적임
- 비밀번호 구성 규칙: NIST는 비밀번호 구성 규칙을 "권장하지 않음"에서 "허용하지 않음"으로 변경. 이는 보안 강화를 위한 중요한 단계임
- 산업 표준과의 충돌: 일부 산업 표준(예: PCI, ISO 27001:2022)은 여전히 NIST와 상충되는 요구 사항을 가지고 있음. 이는 기업들이 새로운 NIST 규칙을 따르기 어렵게 만듦
- 비밀번호 관리자 사용: 비밀번호 관리자는 웹사이트뿐만 아니라 다양한 시스템에서 유용함. 하드웨어 토큰이나 생체 인증을 통해 마스터 비밀번호를 입력하는 방법도 있음.
- 비밀번호 길이 제한: 비밀번호 길이 제한은 인증 시스템의 자원 고갈을 방지하기 위한 것. 하지만 너무 짧은 비밀번호 제한은 보안에 심각한 제약을 줄 수 있음.
GN⁺의 정리
- NIST의 새로운 비밀번호 규칙은 기존의 불필요하고 해로운 보안 요구 사항을 제거하여 보안을 강화함.
- 유니코드 비밀번호 허용은 국제 사용자들에게 큰 도움이 될 것임.
- 일부 산업 표준과의 충돌로 인해 기업들이 새로운 규칙을 따르기 어려울 수 있음.
- 비밀번호 관리자는 다양한 시스템에서 유용하며, 하드웨어 토큰을 통해 보안을 강화할 수 있음.
- 비밀번호 길이 제한은 자원 고갈을 방지하기 위한 것이지만, 너무 짧은 제한은 보안에 문제를 일으킬 수 있음.
이거 보시는 UI 관계자 분들 계시면 패스워드 입력시에 화면에 출력되는 가상 키보드로 입력하는 걸 강제하는 UI도 제발 없애주시기 바랍니다.
처음 나온 건 패스워드가 키로거에 의해 노출되는 걸 방지하기 위해서였겠지만, 요즘은 이곳 저곳에 널린 카메라에 찍혀서 패스워드가 노출될 위험이 훨씬 큽니다.
볼 때마다 당황스러운 UI인데 아직도 유지되고 있는게 이상해요.
아마도 키로거 때문에 만들어졌다는 건 이미 망각했고, 그냥 다들 그렇게 하니까 따라 하는게 아닐까 의심됩니다.
정부 보안 가이드라서 그래요. 가상 키보드 넣고 싶은 업체는 아무도 없을거에요.
각종 표준 인증에도 가상 키보드 필수 사항들이 있는 것들이 많습니다. 그게 생각보다 세부 요구 사항이 많은데, 이걸 구현한 기존 업체 제품(sdk)을 쓰지 않으면 심사에 시간이 더 걸리거나 리젝되기도 해요. 사실 이건 보안 업체 카르텔이 아닐까 싶을 정도죠.
아직도 틀니 끼신 분들은 옛날식 보안이 최고로 안전하다 믿고 계십니다.
내가 검증하지 않은 것은 검증된 게 아니라는 게 그들 사고방식이죠.
시장은 그 틀니끼신 분을 따라가게 되어 있고요. 공공은 특히 더욱 더.
대한민국에 흔한 보안
- 비밀번호는 8~12자까지 (최소는 문제가 아니지만 대체 최대 길이는 왜 존재하는 것인가)
- ID 는 영문/숫자 혼합 강제
- 특수문자는 (...)만 강요 (특히 SQL 인젝션 유발하는 기호 사용을 의도적으로 차단)
- 비밀번호는 30일마다 변경 강제 정책 (대기업일 수록... 최악으로는 15일마다 한 번 변경 요구하는 곳도 있음)
- OTP 같은 다단계 인증을 요구하는 국내 사이트는 거의 없는 수준
(포털엔 있기라도 하지만 커뮤니티 사이트는 디씨 말고는 없는 수준)
최대 길이가 짧은 곳은 좀 그렇더군요.
사실 비밀번호는
조아백반0212341234점심특선1인분카드요
처럼 '이미 있는 단어'의 조합이라 할지라도 여러개가 이어지면 난이도가 급상승하거든요.
그 개발문화 그나마 낫다는 쿠팡도 아무 시각적 피드백 없이 조용히 비밀번호 길이를 16자로 제한하더라구요. 비밀번호 변경 메일도 없었고 아무 이유없이 로그인이 안돼서 해킹당한 건 줄 알았습니다
개발 분야에도 여러 영역이 있어서인가봐요. 보안이나 접근성은 다뤄지지 않는 대표적인 분야인 것 같아요. 다크 패턴에 쏟는 노력의 조금이라도 ...
지금 확인해보니 상한이 20자로 조정됐네요. 하지만 여전히 회원가입 웹페이지에서는 비밀번호에 대한 어떠한 안내문이나 시각적 피드백도 없이 비밀번호 길이를 제한하고 로그인 웹페이지에서는 아무런 제한이 없습니다. 반면에 안드로이드 앱 비밀번호 변경 페이지에서는 비밀번호 규칙을 정확히 명시하고 있습니다. 안드로이드 팀과 웹 프론트엔드 팀끼리 손발이 안 맞는 것 같네요
전형적인 사일로화의 현상이라 생각합니다
비밀번호 최대길이가 12자 정도로 짧거나 특수기호를 허용하지 않는 사이트들은 사용하기 꺼려집니다. 보안에 신경쓰지 않는다는 신호중 하나로 보입니다
Hacker News 의견
-
NIST는 2017년부터 비밀번호 구성 규칙을 완화하는 지침을 제공해 왔음
- "검증자는 암기된 비밀번호에 대해 다른 구성 규칙을 강요하지 말아야 함"
- "검증자는 임의로 비밀번호를 변경하도록 요구하지 말아야 함"
- "인증자가 손상된 증거가 있을 경우 변경을 강제해야 함"
-
NIST는 정책을 설정하지 않지만, 많은 다른 정책들이 NIST 800-63을 참조함
-
웹사이트 가입 시 "좋은 비밀번호는 a, b, c를 사용해야 한다"는 규칙이 매우 짜증났음
- 많은 사이트 개발자들이 좋은 비밀번호에 대해 잘 모르는 것 같음
-
NIST는 '보안 질문'도 금지함 (예: "어머니의 성함은?")
-
NIST는 몇십 년 동안 잘못된 비밀번호 지침을 제공하다가 이제서야 더 합리적인 해결책으로 변경함
- 이전의 잘못된 지침으로 인해 많은 소프트웨어가 구축되었고, 이를 변경하는 데 오랜 시간이 걸릴 것임
-
bcrypt 문제로 인해 "제출된 비밀번호 전체를 검증해야 한다"는 요구사항이 생긴 것 같음
-
NIST는 최대 비밀번호 길이를 64자로 제안함 (많은 사이트는 20자로 제한하여 암호 구문 사용이 불가능했음)
-
한 사용자의 이야기:
- 아내의 은행은 지난달까지 숫자 ID를 로그인으로 사용했음
- 이번 달부터 사용자 이름을 선택하도록 강제했으며, 대문자와 숫자를 포함해야 했음
- 이 은행은 유럽에서 8번째로 큰 은행임
-
특정 문자를 요구하는 것이 엔트로피를 증가시키는지 감소시키는지에 대한 논쟁이 있음
- 특정 문자를 요구하면 선택할 수 있는 문자의 범위가 줄어들어 엔트로피가 감소함
- 대부분의 사용자는 약한 비밀번호를 선택하므로 특정 문자를 요구하면 엔트로피가 증가할 수 있음
- 그러나 대부분의 사용자는 쉽게 추측 가능한 위치에 문자를 배치하기 때문에 엔트로피가 여전히 감소할 것임
-
NIST가 평문 비밀번호를 PAKE로 대체하고, W3C가 이를 위한 메커니즘을 마련하기를 기다리고 있음
-
원본 링크: NIST SP 800-63b