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

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

---

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

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

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

---

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

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

---

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

그런 경우에 : (a) 가능한 경우이 사이트를 전염병처럼 사용하지 마십시오. [보안에 대한 견해를 분명히 알고 있습니다] (b) 사이트를 사용해야하는 경우 다른 곳에서 사용하는 비밀번호와 달리 비밀번호가 고유한지 확인하십시오 .

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

[내부적으로, 코드는 처음 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로 작성된 단어를 포함하여 사전 단어가있는 비밀번호를 거부하는 경우에만 효과적입니다.

---

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

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

---

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

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

---

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

---

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

Chances are the bank system is overlaying an older system so they were only able to allow a certain amount of space for the password.

---

My bank does this too. It used to allow any password, and I had a 20 character one. One day I changed it, and lo and behold it gave me a maximum of 8, and had cut out non-alphanumeric characters which were in my old password. Didn't make any sense to me.

All the back-end systems at the bank worked before when I was using my 20 char password with non alpha-numerics, so legacy support can't have been the reason. And even if it was, they should still allow you to have arbitrary passwords, and then make a hash that fits the requirements of the legacy systems. Better still, they should fix the legacy systems.

A smart card solution would not go well with me. I already have too many cards as it is... I don't need another gimmick.

---

If you accept an arbitrary sized password then one assumes that it is getting truncated to a curtain length for performance reasons before it is hashed. The issue with truncation is that as your server performance increases over time you can't easily increase the length before truncation as its hash would clearly be different. Of course you could have a transition period where both lengths are hashed and checked but this uses more resources.

---

Ignore the people saying not to validate long passwords. Owasp literally says that 128 chars should be enough. Just to give enough breath space you can give a bit more say 300, 250, 500 if you feel like it.

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

Password Length Longer passwords provide a greater combination of characters and consequently make it more difficult for an attacker to guess.

...

Maximum password length should not be set too low, as it will prevent users from creating passphrases. Typical maximum length is 128 characters. Passphrases shorter than 20 characters are usually considered weak if they only consist of lower case Latin characters.

---

Should there be a maximum length? This is a curious topic in IT in that, longer passwords are typically harder to remember, and therefore more likely to get written down (a BIG no-no for obvious reasons). Longer passwords also tend to get forgotten more, which while not necessarily a security risk, can lead to administrative hassles, lost productivity, etc. Admins who believe that these issues are pressing are likely to impose maximum lengths on passwords.

I personally believe on this specific issue, to each user their own. If you think you can remember a 40 character password, then all the more power to you!

Having said that though, passwords are fast becoming an outdated mode of security, Smart Cards and certificate authentication prove very difficult to impossible to brute force as you stated is an issue, and only a public key need be stored on the server end with the private key on your card/computer at all times.

---

Longer passwords, or pass-phrases, are harder to crack simply based on length, and easier to remember than requiring a complex password.

Probably best to go for a fairly long (10+) minimum length, restricting the length useless.

---

Legacy systems (mentioned already) or interfacing outside vendor's systems might necessitate the 8 character cap. It could also be a misguided attempt to save the users from themselves. Limiting it in that fashion will result in too many pssw0rd1, pssw0rd2, etc. passwords in the system.

---

One reason passwords may not be hashed is the authentication algorithm used. For example, some digest algorithms require a plaintext version of the password at the server as the authentication mechanism involves both the client and the server performing the same maths on the entered password (which generally won't produce the same output each time as the password is combined with a randomly generated 'nonce', which is shared between the two machines).

Often this can be strengthened as the digest can be part computed in some cases, but not always. A better route is for the password to be stored with reversible encryption - this then means the application sources need to be protected as they'll contain the encryption key.

Digst auth is there to allow authentication over otherwise non-encrypted channels. If using SSL or some other full-channel encryption, then there's no need to use digest auth mechanisms, meaning passwords can be stored hashed instead (as passwords could be sent plaintext over the wire safely (for a given value of safe).

---

Try not to impose any limitation unless necessary. Be warned: it might and will be necessary in a lot of different cases. Dealing with legacy systems is one of these reasons. Make sure you test the case of very long passwords well (can your system deal with 10MB long passwords?). You can run into Denial of Service (DoS) problems because the Key Defivation Functions (KDF) you will be using (usually PBKDF2, bcrypt, scrypt) will take to much time and resources. Real life example: http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/

---

Just 8 char long passwords sound simply wrong. If there ought to be a limit, then atleast 20 char is better idea.

---

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

참고 URL : https://stackoverflow.com/questions/98768/should-i-impose-a-maximum-length-on-passwords