우리가 흔히 아는 영수특 혼합이나 몇개월에 한번 비밀번호 변경을 요구하는 룰은 사실 미국 정부 산하의 NIST(국립 표준 및 기술 연구소)라는 연구소에서 정한 룰을 수입한 것입니다. 그러나 해묵은 그 룰에 문제가 있다는 판단을 내린 NIST 측은 2020년 그 부분을 완전히 새롭게 작성한 ‘디지털 신원 가이드라인 – 인증 및 수명 주기 관리’ 라는 문서를 공개했습니다.
이 문서에서는 비밀번호에 대해 우리가 아는 많은 상식을 깨고 있습니다.
Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length. All printing ASCII [RFC 20] characters as well as the space character SHOULD be acceptable in memorized secrets. Unicode [ISO/ISC 10646] characters SHOULD be accepted as well. To make allowances for likely mistyping, verifiers MAY replace multiple consecutive space characters with a single space character prior to verification, provided that the result is at least 8 characters in length. Truncation of the secret SHALL NOT be performed. For purposes of the above length requirements, each Unicode code point SHALL be counted as a single character. (중략)
Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets.
In order to assist the claimant in successfully entering a memorized secret, the verifier SHOULD offer an option to display the secret — rather than a series of dots or asterisks — until it is entered. This allows the claimant to verify their entry if they are in a location where their screen is unlikely to be observed. The verifier MAY also permit the user’s device to display individual entered characters for a short time after each character is typed to verify correct entry. This is particularly applicable on mobile devices.
검증자는 가입자가 선택한 암기된 비밀의 길이가 최소 8자 이상이어야 하도록 요구해야 합니다. 검증자는 가입자가 선택한 암기된 비밀번호의 길이가 최소 64자 이상이 되도록 허용해야 합니다. 외우는 비밀번호에는 공백 문자뿐만 아니라 모든 인쇄용 ASCII [RFC 20] 문자를 사용할 수 있어야 합니다. 유니코드 [ISO/ISC 10646] 문자도 허용되어야 합니다. 오타 가능성에 대비하기 위해 검증자는 확인 전에 여러 개의 연속된 공백 문자를 하나의 공백 문자로 대체할 수 있으며, 그 결과 길이가 8자 이상인 경우에만 허용됩니다. 시크릿을 잘라내서는 안 됩니다. 위의 길이 요구 사항의 목적상 각 유니코드 코드 포인트는 단일 문자로 계산되어야 합니다. (중략)
검증자는 암기된 암호에 대해 다른 구성 규칙(예: 다른 문자 유형의 혼합을 요구하거나 연속적으로 반복되는 문자를 금지하는 등)을 부과해서는 안 됩니다. 검증자는 암기된 비밀번호를 임의로 변경하도록 요구해서는 안 됩니다(예: 주기적으로). 그러나, 검증자는 인증자가 손상된 증거가 있는 경우 강제로 변경해야 합니다.
검증자는 청구자가 암기된 비밀번호를 입력할 때 “붙여넣기” 기능을 사용할 수 있도록 허용해야 합니다. 이는 널리 사용되는 비밀번호 관리자의 사용을 용이하게 하며, 많은 경우 사용자가 더 강력한 암기 비밀번호를 선택할 가능성을 높입니다.
청구인이 암기된 비밀번호를 성공적으로 입력하는 데 도움을 주기 위해 검증자는 비밀번호를 입력할 때까지 점이나 별표 대신 비밀번호를 표시하는 옵션을 제공해야 합니다. 이렇게 하면 청구인이 화면을 볼 수 없는 위치에 있는 경우에도 자신의 입력을 확인할 수 있습니다. 또한 확인자는 올바른 입력 여부를 확인하기 위해 각 문자를 입력한 후 잠시 동안 사용자의 장치에 입력된 개별 문자를 표시하도록 허용할 수도 있습니다. 이는 특히 모바일 장치에 적용됩니다.
5.1.1.1 Memorized Secret Verifiers
그 뿐 아닙니다. 부록에는 암호의 길이와 복잡성에 대한 내용을 적고 있는데,
As noted above, composition rules are commonly used in an attempt to increase the difficulty of guessing user-chosen passwords. Research has shown, however, that users respond in very predictable ways to the requirements imposed by composition rules [Policies]. For example, a user that might have chosen “password” as their password would be relatively likely to choose “Password1” if required to include an uppercase letter and a number, or “Password1!” if a symbol is also required.
Users also express frustration when attempts to create complex passwords are rejected by online services. Many services reject passwords with spaces and various special characters. In some cases, the special characters that are not accepted might be an effort to avoid attacks like SQL injection that depend on those characters. But a properly hashed password would not be sent intact to a database in any case, so such precautions are unnecessary. Users should also be able to include space characters to allow the use of phrases. Spaces themselves, however, add little to the complexity of passwords and may introduce usability issues (e.g., the undetected use of two spaces rather than one), so it may be beneficial to remove repeated spaces in typed passwords prior to verification.
Users’ password choices are very predictable, so attackers are likely to guess passwords that have been successful in the past. These include dictionary words and passwords from previous breaches, such as the “Password1!” example above. For this reason, it is recommended that passwords chosen by users be compared against a “black list” of unacceptable passwords. This list should include passwords from previous breach corpuses, dictionary words, and specific words (such as the name of the service itself) that users are likely to choose. Since user choice of passwords will also be governed by a minimum length requirement, this dictionary need only include entries meeting that requirement.
Highly complex memorized secrets introduce a new potential vulnerability: they are less likely to be memorable, and it is more likely that they will be written down or stored electronically in an unsafe manner. While these practices are not necessarily vulnerable, statistically some methods of recording such secrets will be. This is an additional motivation not to require excessively long or complex memorized secrets.
위에서 언급한 바와 같이, 구성 규칙은 일반적으로 사용자가 선택한 비밀번호를 추측하기 어렵게 하기 위해 사용됩니다. 그러나 연구에 따르면 사용자는 구성 규칙[정책]에 의해 부과된 요구 사항에 대해 매우 예측 가능한 방식으로 반응하는 것으로 나타났습니다. 예를 들어, “password”를 비밀번호로 선택한 사용자는 대문자와 숫자를 포함해야 하는 경우 “Password1″을, 기호도 포함해야 하는 경우 “Password1!”을 선택할 가능성이 상대적으로 높습니다.
또한 복잡한 비밀번호를 만들려는 시도가 온라인 서비스에서 거부될 때 사용자들은 불만을 표합니다. 많은 서비스에서 공백과 다양한 특수 문자가 포함된 비밀번호를 거부합니다. 경우에 따라 허용되지 않는 특수 문자는 이러한 문자에 의존하는 SQL 인젝션과 같은 공격을 피하기 위한 노력일 수 있습니다. 그러나 제대로 해시된 비밀번호는 어떤 경우에도 데이터베이스에 그대로 전송되지 않으므로 이러한 예방 조치는 불필요합니다. 또한 사용자는 구문 사용을 허용하기 위해 공백 문자를 포함할 수 있어야 합니다. 그러나 공백 자체는 비밀번호의 복잡성을 거의 증가시키지 않으며 사용성 문제(예: 공백이 하나가 아닌 두 개가 감지되지 않는 경우)를 야기할 수 있으므로 입력된 비밀번호에서 반복되는 공백은 확인 전에 제거하는 것이 좋습니다.
사용자의 비밀번호 선택은 매우 예측 가능하므로 공격자는 과거에 성공했던 비밀번호를 추측할 가능성이 높습니다. 여기에는 위의 “Password1!” 예시와 같이 사전 단어와 이전 침해 사례에서 사용된 비밀번호가 포함됩니다. 따라서 사용자가 선택한 비밀번호를 허용되지 않는 비밀번호의 ‘블랙 리스트’와 비교하는 것이 좋습니다. 이 목록에는 이전 침해 사례의 비밀번호, 사전 단어, 사용자가 선택할 가능성이 있는 특정 단어(예: 서비스 이름)가 포함되어야 합니다. 사용자가 선택하는 비밀번호에는 최소 길이 요건이 적용되므로 이 사전에는 해당 요건을 충족하는 항목만 포함하면 됩니다.
매우 복잡하게 외워야 하는 비밀번호는 기억하기 어렵고, 안전하지 않은 방식으로 전자적으로 기록하거나 저장할 가능성이 높다는 새로운 잠재적 취약점을 야기합니다. 이러한 관행이 반드시 취약한 것은 아니지만, 통계적으로 이러한 비밀을 기록하는 방법 중 일부는 취약한 것으로 나타났습니다. 따라서 지나치게 길거나 복잡한 비밀번호를 외우도록 요구하지 않는 것이 좋습니다.
A.3 Complexity
이 문서가 정식으로 공개 된 것이 2020년의 일입니다만, 우리 정보보안 당국은 ‘우리 민족 끼리’를 외치고 있는 것이 현실입니다. 그런데 미국 정부는 여기서 한술 더 뜨고 있습니다. 2022년 공개된 이 문서의 개정판에서는 비밀번호에 관한 요구사항이 보다 더 강제성을 띄도록 변경되었습니다. Should나 Should not이 Shall이나 Shall not이 되어버린 것이죠.
자, 우리나라 정부와 기업들은 어떻게 나올까요?