비밀번호에 최대 길이를 지정해야 합니까?

https://stackoverflow.com/questions/98768

01-07-2019
|

문제

비밀번호에 최소 길이를 부과하는 것이 (사용자를 스스로로부터 보호하기 위해) 많은 의미가 있다는 것을 이해합니다. 은행 비밀번호 길이가 6~8자여야 한다는 요구 사항이 있는데 궁금해지기 시작했습니다.

이것이 무차별 대입 공격을 더 쉽게 만들어주지 않을까요?(나쁜)
이는 내 비밀번호가 암호화되지 않은 상태로 저장된다는 의미입니까?(나쁜)

(희망적으로) 유능한 IT 보안 전문가가 있는 누군가가 최대 비밀번호 길이를 부과한다면 비슷한 조치를 취해야 할까요?이것의 장점/단점은 무엇입니까?

해결책

비밀번호는 길이에 관계없이 32, 40, 128로 해시됩니다.최소 길이를 설정하는 유일한 이유는 비밀번호를 쉽게 추측할 수 없도록 하기 위한 것입니다.최대 길이에 대한 목적은 없습니다.

의무사항 XKCD 최대 길이를 부과하면 사용자에게 해를 끼치는 이유를 설명합니다.

다른 팁

비밀번호 필드에 지정된 최대 길이는 다음과 같이 읽어야 합니다. 보안 경고:현명하고 보안에 민감한 사용자라면 최악의 상황을 가정하고 이 사이트가 귀하의 비밀번호를 문자 그대로 저장하고 있을 것으로 예상해야 합니다(예:epochwolf의 설명대로 해시되지 않음).

그 경우는 다음과 같습니다.(a) 가능한 경우 전염병과 같은이 사이트를 사용하지 마십시오.

비밀번호를 허용하는 사이트를 개발하는 경우 동일한 브러시로 인해 타르를 당하고 싶지 않은 한 어리석은 비밀번호 제한을 설정하지 마십시오.

[물론 내부적으로 코드는 엄청난 비밀번호를 처리하는 것을 피하기 위해 첫 번째 256/1028/2k/4k(무엇이든) 바이트만 "중요"한 바이트로 처리할 수 있습니다.]

완전히 제한되지 않은 비밀번호 길이를 허용하는 것은 신뢰할 수 없는 소스의 비밀번호를 수락하는 경우 한 가지 큰 단점이 있습니다.

발신자는 너무 긴 비밀번호를 제공하여 다른 사람의 서비스가 거부될 수 있습니다.예를 들어, 비밀번호가 1GB의 데이터이고 메모리가 부족할 때까지 모든 시간을 소비했다면 이를 수락하세요.이제 이 사람이 귀하가 수락할 의사가 있는 만큼 이 비밀번호를 보낸다고 가정해 보겠습니다.관련된 다른 매개 변수에 주의하지 않으면 DoS 공격이 발생할 수 있습니다.

상한을 256자 정도로 설정하는 것은 오늘날의 기준으로 볼 때 지나치게 관대해 보입니다.

첫째, 은행에 훌륭한 IT 보안 전문가가 있다고 가정하지 마십시오. 그렇지 않은 경우가 많음.

즉, 최대 비밀번호 길이는 쓸모가 없습니다.종종 사용자에게 새 비밀번호를 생성하도록 요구하므로(현재는 모든 사이트에서 서로 다른 비밀번호를 사용하는 것의 가치에 대한 논쟁), 이를 그냥 적어둘 가능성이 높아집니다.또한 무차별 대입부터 사회 공학에 이르기까지 모든 벡터에 의한 공격에 대한 취약성이 크게 증가합니다.

이제 OWASP 인증 치트 시트에서 최대 비밀번호 길이 제한을 권장하지 않습니다.

https://www.owasp.org/index.php/Authentication_Cheat_Sheet

전체 단락을 인용하면 다음과 같습니다.

암호가 길수록 문자 조합이 더 많아지고 결과적으로 공격자가 추측하기가 더 어려워집니다.

애플리케이션에서는 비밀번호의 최소 길이를 적용해야 합니다.10자보다 짧은 비밀번호는 취약한 것으로 간주됩니다([1]).최소 길이를 적용하면 일부 사용자의 비밀번호를 기억하는 데 문제가 발생할 수 있지만 애플리케이션은 일반 비밀번호보다 훨씬 길고 기억하기 훨씬 쉬운 비밀번호 문구(문장 또는 단어 조합)를 설정하도록 권장해야 합니다.

최대 비밀번호 길이를 너무 낮게 설정하면 사용자가 비밀번호 문구를 생성할 수 없게 되므로 너무 낮게 설정하면 안 됩니다.일반적인 최대 길이는 128자입니다.20자보다 짧은 암호 문구는 라틴 소문자로만 구성된 경우 일반적으로 취약한 것으로 간주됩니다.모든 캐릭터가 중요합니다!!

사용자가 입력하는 모든 문자가 실제로 비밀번호에 포함되어 있는지 확인하세요.사용자가 제공한 것보다 짧은 길이로 비밀번호를 자르는 시스템을 본 적이 있습니다(예: 20자를 입력하면 15자로 잘림).이는 일반적으로 모든 비밀번호 입력 필드의 길이를 최대 비밀번호 길이와 정확히 동일하게 설정하여 처리됩니다.이는 최대 비밀번호 길이가 20~30자처럼 짧은 경우 특히 중요합니다.

최대 비밀번호 길이를 적용하는 이유 중 하나는 프런트엔드가 많은 레거시 시스템 백엔드와 인터페이스해야 하고 그 중 하나가 최대 비밀번호 길이를 적용해야 하는 경우입니다.

또 다른 사고 과정은 사용자가 짧은 비밀번호를 사용해야 하는 경우 (친구/가족이) 쉽게 추측할 수 있는 캐치프레이즈나 별명보다 임의의 횡설수설을 만들어낼 가능성이 더 높다는 것입니다.물론 이 접근 방식은 프런트엔드가 숫자/문자 혼합을 강제하고 l33t-speak로 작성된 단어를 포함하여 사전 단어가 포함된 비밀번호를 거부하는 경우에만 효과적입니다.

최대 비밀번호 길이를 적용하는 잠재적으로 유효한 이유 중 하나는 비밀번호를 해시하는 프로세스(bcrypt와 같은 느린 해싱 기능 사용으로 인해)가 너무 많은 시간을 차지한다는 것입니다.서버에 대한 DOS 공격을 실행하기 위해 남용될 수 있는 것입니다.

그런 다음 서버는 시간이 너무 오래 걸리는 요청 핸들러를 자동으로 삭제하도록 구성해야 합니다.그래서 나는 이것이 큰 문제가 될 것이라고 의심합니다.

나는 두 가지 요점 모두에서 당신이 매우 옳다고 생각합니다.해시된 비밀번호를 저장하는 경우 비밀번호 길이는 DB 스키마에 전혀 영향을 미치지 않습니다.개방형 암호 길이를 사용하면 무차별 대입 공격자가 고려해야 할 변수가 하나 더 추가됩니다.

잘못된 디자인 외에는 비밀번호 길이를 제한하는 데 대한 변명을 찾기가 어렵습니다.

최대 비밀번호 길이에 대해 제가 볼 수 있는 유일한 이점은 지나치게 긴 비밀번호로 인해 발생하는 버퍼 오버플로 공격의 위험을 제거하는 것입니다. 그러나 이러한 상황을 처리할 수 있는 훨씬 더 나은 방법이 있습니다.

저장 공간은 저렴하지만 비밀번호 길이를 제한하는 이유는 무엇입니까?단순히 해싱하는 것이 아니라 비밀번호를 암호화하는 경우에도 64자 문자열을 암호화하는 데에는 6자 문자열 이상이 필요하지 않습니다.

은행 시스템이 이전 시스템을 오버레이하여 비밀번호에 일정량의 공간만 허용할 수 있었을 가능성이 있습니다.

우리 은행도 이런 일을 해요.이전에는 모든 비밀번호를 허용했는데 저는 20자 비밀번호를 사용했습니다.어느 날 암호를 변경했는데, 보라, 최대 8개가 나왔고, 이전 암호에 있던 영숫자가 아닌 문자가 잘렸습니다.나에게는 아무런 의미가 없었습니다.

영숫자가 아닌 20자 비밀번호를 사용하기 전에는 은행의 모든 백엔드 시스템이 작동했기 때문에 레거시 지원이 이유가 될 수 없었습니다.그리고 설사 그랬더라도 여전히 임의의 비밀번호를 허용하고 레거시 시스템의 요구 사항에 맞는 해시를 만들 수 있어야 합니다.더 좋은 점은 레거시 시스템을 고쳐야 한다는 것입니다.

스마트 카드 솔루션은 나에게 적합하지 않습니다.이미 카드가 너무 많아서..다른 속임수는 필요하지 않습니다.

임의 크기의 비밀번호를 허용하면 해시되기 전에 성능상의 이유로 비밀번호가 커튼 길이로 잘린다고 가정합니다.잘림 문제는 시간이 지남에 따라 서버 성능이 향상됨에 따라 해시가 분명히 다르기 때문에 잘리기 전의 길이를 쉽게 늘릴 수 없다는 것입니다.물론 두 길이가 모두 해시되고 확인되는 전환 기간이 있을 수 있지만 이는 더 많은 리소스를 사용합니다.

긴 비밀번호를 확인하지 말라고 말하는 사람들을 무시하세요.Owasp는 문자 그대로 128자이면 충분하다고 말합니다.충분한 호흡 공간을 제공하기 위해 원한다면 300, 250, 500을 조금 더 줄 수 있습니다.

https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Password_Length

비밀번호 길이 긴 암호는 더 큰 문자 조합을 제공하므로 결과적으로 공격자가 추측하기가 더 어려워집니다.

...

사용자가 암호를 생성하지 못하므로 최대 비밀번호 길이를 너무 낮게 설정해서는 안됩니다. 일반적인 최대 길이는 128 자입니다.20 자보다 짧은 암호는 소문자 라틴 문자로만 구성되면 일반적으로 약한 것으로 간주됩니다.

최대 길이가 있어야 합니까?이는 일반적으로 암호가 길수록 기억하기 어렵고 기록해 두기 쉽다는 점에서 IT 분야에서 흥미로운 주제입니다(명백한 이유로 큰 금지 사항).비밀번호가 길수록 더 많이 잊어버리는 경향이 있는데, 이는 반드시 보안 위험은 아니지만 관리상의 번거로움, 생산성 저하 등을 초래할 수 있습니다.이러한 문제가 시급하다고 생각하는 관리자는 비밀번호에 최대 길이를 부과할 가능성이 높습니다.

저는 개인적으로 이 특정 문제가 각 사용자마다 다르다고 믿습니다.40자 비밀번호를 기억할 수 있다고 생각한다면 더 많은 힘을 얻을 수 있습니다!

하지만 비밀번호는 빠르게 구식 보안 모드가 되어가고 있습니다. 스마트 카드와 인증서 인증은 귀하가 언급한 것처럼 무차별 대입 공격이 매우 어렵거나 불가능하다는 것이 입증되었으며 공개 키만 개인 키와 함께 서버 측에 저장하면 됩니다. 항상 카드/컴퓨터에 키를 두십시오.

긴 암호 또는 암호 문구는 단순히 길이에 따라 해독하기 어렵고 복잡한 암호를 요구하는 것보다 기억하기가 더 쉽습니다.

아마도 상당히 긴(10+) 최소 길이를 사용하여 길이를 쓸모없게 제한하는 것이 가장 좋습니다.

이미 언급한 레거시 시스템이나 외부 공급업체 시스템과의 인터페이스에는 8자 제한이 필요할 수 있습니다.또한 사용자를 스스로 구하려는 잘못된 시도일 수도 있습니다.이러한 방식으로 제한하면 pssw0rd1, pssw0rd2 등이 너무 많아집니다.시스템의 비밀번호.

비밀번호가 해시되지 않는 한 가지 이유는 사용되는 인증 알고리즘 때문입니다.예를 들어 일부 다이제스트 알고리즘 인증 메커니즘에는 입력된 비밀번호에 대해 동일한 계산을 수행하는 클라이언트와 서버가 모두 포함되므로 서버에서 비밀번호의 일반 텍스트 버전이 필요합니다. 일반적으로 비밀번호가 무작위로 생성된 비밀번호와 결합될 때마다 동일한 출력이 생성되지 않습니다. 두 시스템 간에 공유되는 'nonce').

경우에 따라 다이제스트를 부분적으로 계산할 수 있으므로 이는 종종 강화될 수 있지만 항상 그런 것은 아닙니다.더 나은 경로는 암호를 해독 가능한 암호화로 저장하는 것입니다. 이는 애플리케이션 소스에 암호화 키가 포함되어 있으므로 보호해야 함을 의미합니다.

Digst 인증은 암호화되지 않은 채널을 통한 인증을 허용하기 위해 존재합니다.SSL 또는 기타 전체 채널 암호화를 사용하는 경우 다이제스트 인증 메커니즘을 사용할 필요가 없습니다. 즉, 비밀번호는 해시된 상태로 저장될 수 있습니다(비밀번호는 지정된 safe 값에 대해 유선을 통해 안전하게 일반 텍스트로 전송될 수 있기 때문입니다).

꼭 필요한 경우가 아니면 제한을 두지 마십시오.경고 받다:그것은 다양한 경우에 필요할 수도 있고 필요할 것입니다.레거시 시스템을 다루는 것도 이러한 이유 중 하나입니다.매우 긴 암호의 경우를 잘 테스트해야 합니다(시스템이 10MB의 긴 암호를 처리할 수 있습니까?).사용하게 될 KDF(Key Defivation Function)(일반적으로 PBKDF2, bcrypt, scrypt)에 많은 시간과 리소스가 소요되기 때문에 DoS(서비스 거부) 문제가 발생할 수 있습니다.실제 사례: http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/

단지 8자 길이의 비밀번호가 단순히 잘못된 것처럼 들립니다.제한이 있어야 한다면 최소한 20자 정도가 더 좋습니다.

적용해야 할 유일한 제한은 2000자 제한이나 기타 엄청나게 높은 제한과 같지만 그것이 문제인 경우에만 데이터베이스 크기를 제한하는 것입니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow