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

암호에 최소 길이를 적용하면 사용자를 보호하기 위해 많은 의미가 있지만 은행 에 암호의 길이는 6 ~ 8 자 여야한다는 궁금한 점이 있습니다.

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

좋은 IT 보안 전문가를 고용하고있는 누군가가 최대 암호 길이를 부과하는 경우 비슷한 작업을 생각해야합니까? 이것의 장단점은 무엇입니까?

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

최대 길이를 부과하는 경우 사용자에게 서비스를 중단하는 이유를 설명 하는 필수 XKCD :

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

그 경우입니다 :

1. 가능하면이 사이트를 전염병처럼 사용하지 마십시오. 그들은 분명히 보안에 대해 아무것도 모른다.
2. 사이트를 반드시 사용해야하는 경우 다른 곳에서 사용하는 비밀번호와 달리 비밀번호가 고유해야합니다.

비밀번호를 허용하는 사이트를 개발하는 경우 동일한 브러시로 타르 팅 하지 않으려 는 경우 바보 같은 비밀번호 제한을 두지 마십시오 .

[내부적으로, 코드는 매머드 암호의 크 런칭을 피하기 위해 처음 256 / 1024 / 2k / 4k / (무엇보다) 바이트 만 "유의 한"바이트로 취급 할 수 있습니다.]

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

발신자가 다른 사람에게 서비스 거부를 초래할 정도로 긴 암호를 제공하려고 할 수 있습니다. 예를 들어, 암호가 1GB의 데이터이고 메모리가 부족할 때까지 모든 시간을 소비하는 경우. 이제이 사람이 당신이 수락하고자하는 횟수만큼이 암호를 보낸다고 가정 해보십시오. 관련된 다른 매개 변수에주의하지 않으면 DoS 공격이 발생할 수 있습니다.

256 개의 문자로 상한을 설정하는 것은 오늘날의 표준에 의해 지나치게 관대 해 보입니다.

첫째, 은행에 훌륭한 IT 보안 전문가가 있다고 가정하지 마십시오. 충분하지 않습니다 .

즉, 최대 암호 길이는 쓸모가 없습니다. 사용자는 종종 새 비밀번호 (현재 모든 사이트에서 다른 비밀번호를 사용하는 가치에 대한 논쟁)를 작성해야하므로, 비밀번호를 적을 가능성이 높아집니다. 또한 무차별 대입에서 사회 공학에 이르는 모든 벡터를 통해 공격에 대한 취약성을 크게 높입니다.

OWASP Authentication Cheat Sheet에서 최대 암호 길이를 128 자 미만으로 설정하지 않는 것이 좋습니다.

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

전체 단락을 인용 :

암호가 길수록 더 많은 문자 조합이 제공되므로 공격자가 추측하기가 더 어려워집니다.

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

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

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

최대 암호 길이를 적용한다고 생각할 수있는 한 가지 이유는 프런트 엔드가 많은 레거시 시스템 백엔드와 인터페이스해야하는데 그 중 하나가 최대 암호 길이를 적용하는 것입니다.

또 다른 사고 과정은 사용자가 짧은 암호를 사용하도록 강요 받으면 쉽게 추측 할 수있는 친구 / 가족이 붙잡는 어구 또는 별명보다 임의의 횡설수설을 할 가능성이 높다는 것입니다. 이 접근법은 물론 프론트 엔드가 숫자 / 문자 혼합을 강제하고 l33t-speak로 작성된 단어를 포함하여 사전 단어가있는 비밀번호를 거부하는 경우에만 효과적입니다.

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

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

두 글 머리 기호 모두에 대해 옳다고 생각합니다. 비밀번호를 해시 된대로 저장하는 경우 비밀번호 길이는 DB 스키마에 영향을 미치지 않습니다. 개방형 암호 길이를 가지면 무차별 대입 공격자가 고려해야 할 변수가 하나 더 발생합니다.

잘못된 디자인 외에 암호 길이 제한에 대한 변명을보기는 어렵습니다.

최대 암호 길이를 알 수있는 유일한 이점은 너무 긴 암호로 인한 버퍼 오버플로 공격의 위험을 제거하는 것이지만 해당 상황을 처리하는 더 좋은 방법이 있습니다.

긴 암호의 유효성을 검사하지 말 것을 사람들이 무시하십시오. Owasp는 문자 그대로 128 자이면 충분하다고 말합니다. 충분한 호흡 공간을 제공하기 위해 300, 250, 500과 같은 느낌을 줄 수 있습니다.

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

암호 길이가 길수록 더 많은 문자 조합이 제공되므로 공격자가 추측하기가 더 어려워집니다.

...

사용자가 암호를 만들 수 없으므로 최대 암호 길이를 너무 낮게 설정해서는 안됩니다. 일반적인 최대 길이는 128 자 입니다. 20 자 미만의 암호는 소문자 라틴 문자로만 구성된 경우 일반적으로 약한 것으로 간주됩니다.

저장 비용이 저렴하므로 비밀번호 길이가 제한되는 이유는 무엇입니까? 비밀번호를 해싱하는 대신 비밀번호를 암호화하더라도 64 자 문자열은 6 자 이상의 문자열을 암호화하는 데 걸리지 않습니다.

은행 시스템이 구형 시스템을 오버레이하여 암호에 대해 일정량의 공간 만 허용 할 수 있습니다.

우리 은행도이 일을합니다. 그것은 모든 암호를 허용하는 데 사용되었으며 20 자 암호가 있습니다. 어느 날 나는 그것을 바꾸었고, 보라, 그것은 나에게 최대 8을 주었고, 내 이전 암호에있는 영숫자가 아닌 문자를 잘라 냈습니다. 나에게 이해가되지 않았다.

영숫자가 아닌 문자로 20 자 암호를 사용할 때 은행의 모든 ​​백엔드 시스템이 작동했기 때문에 레거시 지원이 그 이유가 될 수 없었습니다. 그리고 암호가 여전히 그렇더라도 여전히 임의의 암호를 보유한 다음 레거시 시스템의 요구 사항에 맞는 해시를 만들 수 있어야합니다. 더 좋은 점은 레거시 시스템을 수정해야합니다.

스마트 카드 솔루션은 나와 잘 어울리지 않습니다. 이미 카드가 너무 많습니다. 다른 특수 효과가 필요하지 않습니다.

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

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

최대 길이가 있어야합니까? 이것은 암호가 길수록 일반적으로 기억하기 어렵고 따라서 기록 될 가능성이 더 높다는 점에서 IT의 흥미로운 주제입니다 (명백한 이유는 전혀 없습니다). 암호가 길수록 암호를 잊어 버리는 경향이 있습니다. 보안 위험은 아니지만 관리상의 번거 로움, 생산성 저하 등으로 이어질 수 있습니다. 이러한 문제를 겪고 있다고 생각하는 관리자는 암호에 최대 길이를 부과 할 수 있습니다.

나는 개인적으로 각 사용자 에게이 특정 문제를 믿습니다. 당신이 당신이 40 문자 암호를 기억할 수 있다고 생각한다면, 당신에게 더 많은 힘을!

그럼에도 불구하고 암호는 구식 보안 모드로 빠르게 변하고 있지만 스마트 카드 및 인증서 인증은 문제가 있다고 주장하는 것처럼 무차별 대입하기가 매우 어려우며 공개 키만 개인과 함께 서버에 저장하면됩니다. 항상 카드 / 컴퓨터의 키를 누르십시오.

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

아마도 길이가 매우 길고 (10+) 최소 길이를 유지하는 것이 가장 좋으며 길이는 쓸모가 없습니다.

레거시 시스템 (이미 언급 됨) 또는 공급 업체 시스템 외부와의 인터페이스에는 8 자 제한이 필요할 수 있습니다. 또한 사용자를 자신으로부터 보호하려는 잘못된 시도 일 수도 있습니다. 이러한 방식으로 제한하면 시스템에 너무 많은 pssw0rd1, pssw0rd2 등의 암호가 생성됩니다.

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

다이제스트를 일부 경우에 계산할 수 있기 때문에 종종 강화할 수 있지만 항상 그런 것은 아닙니다. 더 좋은 방법은 암호를 가역 암호화로 저장하는 것입니다. 따라서 암호화 키가 포함되어 있으므로 응용 프로그램 소스를 보호해야합니다.

Digst auth는 암호화되지 않은 채널을 통한 인증을 허용합니다. SSL 또는 다른 전체 채널 암호화를 사용하는 경우 다이제스트 인증 메커니즘을 사용할 필요가 없습니다. 즉, 암호를 유선으로 안전하게 일반 텍스트로 전송할 수 있기 때문에 암호를 해시로 저장할 수 있습니다.

8 자 길이의 암호만으로도 잘못된 소리가납니다. 제한이 있어야한다면 적어도 20 자 이상이 더 좋습니다.

적용해야 할 유일한 제한은 2000 자 제한 또는 다른 것보다 높지만 문제가있는 경우 데이터베이스 크기를 제한하는 것입니다.