10

Rather than adopting a universal standard, many websites develop their own guidelines for how passwords should be constructed.

When you consider the number of passwords the average person today has to create and track, this creates problems for those who have a method for constructing and remembering passwords. For instance, some sites actually limit the length of your password to 12 or fewer characters! There are good reasons for enforcing a minimum length, but not to stop a person from using a longer passphrase. 50 characters would be a more reasonable upper limit.

I can understand that certain organizations like the government and the military might want to pursue guidelines that are more stringent than most websites need; however, wouldn't having some universal baseline be practical? Is some organization working to bring this about?

Mario
  • 423
  • 4
  • 11

4 Answers4

18

Password strength metres are often wrong in their appreciation of what makes a password good. Often they ask you to pick special characters with little regard for how guessable your produced password is. See Telepathwords for an example of what an informed password strength metre should look like.

For instance, P@s5WorD. is considered very secure by most password strength metres, yet a good password cracking tool will always check for variations of a dictionary word (especially such a popular one as password), which means you haven't moved from an input space of 26 to 95, but rather an input space of 26 + a few tens of permutations per word in that input space. This is simply due to the way humans make passwords; we don't actually create random passwords because we wouldn't remember them.

A lot password research focuses on helping people create more complex passwords, remember longer passwords or even remember passwords by providing an image on the auth UI meant to act as a reminder, which often ignores the fact that people pick short and similar passwords to cope with the number of credentials they are required to deal with. People don't want to select a password based on some secret/hint your UI provides them, or longer or more complex passwords; they want to remember less and fewer passwords because they've had enough! See this paper from Sasse et al. on an authentication study done... on NIST employees. Also, there are some field studies on how many credentials people manage online (for instance the Floriencio and Herley 2007 paper, which is a bit old already; probably people have many more accounts by now).

Once you've realised that, and the fact that (not always encrypted) password databases get stolen on a daily basis (hence the main issue is not password strength but password handling and storage), you start understanding that the issue is most service providers have no clue why they apply a policy and just mimic whatever they see others do... perpuetating unusable and unscalable password requirements and policies over time.

There was an effort in the past to bring about federated identities with services such as OpenID but service providers preferred to retain control over their customers' identities for a handful of reasons, which means more different authentication interfaces and more passwords for users.

There are interesting initiatives out there to replace passwords (see Pico), but I'm afraid you shouldn't expect any industry improvement over night.

Steve Dodier-Lazaro
  • 6,828
  • 29
  • 45
4

There already is one produced by NIST. And there are good reasons to limit a maximum password length.

Also depending on what industry you are in, standards/requirements may already have been defined. For instance PCI-DSS or the Department of Defence. The problem here is that there are multiple standards, there is no single one.

Bounds have to be set, both upper as lower bounds. In case of passwords an example would be PBKDF2-HMAC-SHA1 (provided that users generate their passwords randomly) a commonly used password hashing algorithm. If the password exceeds 64 bytes in length it will be truncated to 20 bytes (by applyibg a SHA-1 hash to the password) as otherwise it would exceed the blocksize. Of course this is still a lot more than 12 characters, but if you initially plan to use a 70 byte long password it will be reduced to 20 bytes as otherwise the algorithm won't be able to work with the password.

Edit:

A more valid example is listed in the comments. No reason to have passwords which are several MB in size as this does not add any security compared to for instance a 1024 character password. Having such a large password could result in unexpected behaviour within the application.

Lucas Kauffman
  • 54,229
  • 17
  • 113
  • 196
  • 4
    What are the good reasons for an upper limit on length? – David Jun 26 '14 at 17:55
  • 5
    @David: If a user tries to send five gigabytes of data through a password field, treating it like a valid password could consume a lot of resources or trigger unexpected behaviour of code that was not written to handle this gracefully. – Marcks Thomas Jun 26 '14 at 18:41
  • @David read the example. Read the above comment. I'll clarify the example. – Lucas Kauffman Jun 26 '14 at 20:43
  • 1
    @LucasKauffman, that's not truncation. Truncation implies that the last 50 characters are not useful. It would take 27 perfectly random alphanumeric characters in a password to get as much entropy as SHA-1 has, and users don't use perfectly random passwords. – David Jun 26 '14 at 21:07
  • You are correct, but what if you use a password generator to generate random passwords (normal users don't pick 50 character long passwords anyway)? Not that in practice it would matter 20 or 50 characters in PBKDF2 will still take infinity to bruteforce. – Lucas Kauffman Jun 26 '14 at 21:30
  • @LucasKauffman I understand that, with PBKDF2-HMAC-SHA1, any bytes beyond 20 are generally of less entropy value than the first 20. However, this still doesn't give a good reason why 20 should be an upper limit in the password form. If the user's input is translatable to 20 bytes regardless (as is part of the nature of hash functions), why should it matter if they care to have a 100-character password? Sure, leaving the field boundless is asking for trouble. But a 20 character limit is far lower than anything that can be reasonably considered necessary. – Iszi Jun 26 '14 at 22:41
  • Because it won't be any stronger than a 20 character password. So it doesn't really matter if it's 20, 100 or 2000 characters long it will always be reduced to 20 characters before being used to calculate the hmac. It's just an example of why you could set an upper bound limit. Apparently I'm also the only one who generates his passwords randomly. – Lucas Kauffman Jun 27 '14 at 04:20
  • Can you clarify whether you think a longer password should be truncated or kicked back upon creation? Your comments make me believe it should be truncated or hashed first without the users knowledge, but the answer makes it sound like the password should be rejected upon creation due not meeting criteria. – David Houde Jun 27 '14 at 04:25
  • I'm not saying it should be hashed. I'm saying that for that particular algorithm your password will get hashed if it's longer than 20 bytes. That's just how the algorithm works. If the password exceeds the blocksize of 20 bytes it will get truncated. – Lucas Kauffman Jun 27 '14 at 04:37
2

The problem is that you cannot check the strength of a password in the first place. Or more specifically: We can recognize some weak passwords (too short, obvious patterns), but we don't know how a strong password looks like.

Neither the length nor the presence of “special characters” automatically make a password strong. And a relatively short password which only contains alphanumeric characters isn't automatically bad. So any password policy is, at best, a rough attempt at filtering out obvious garbage and making people think about password security.

A universal standard for passwords simply isn't feasible and probably not even sensible. A policy which may work well for one audience may completely fail for a different audience. For example, I mostly generate random passwords with a password manager. Forcing me to follow a certain pattern is nonsensical and annoying. On the other hand, the same policy might actually help somebody with less technical experience. Well, you can't have both. I think the only criterion everybody can agree upon is the minimum length.

Fleche
  • 4,024
  • 1
  • 17
  • 20
  • Why wouldn't it be feasible? Wouldn't some standard for use by *most* online organizations be better than no standard? There is a difference between weak/strong and disallowed/allowed. I'm talking about agreeing on what's allowed. As a simple example: 8-50 chars, no repeating sequences of more than 2 chars, use all 3 character categories (letters, digits, special). A standard algorithm for rating strength could also be specified. Most orgs would not have a need for more than this. – Mario Jun 26 '14 at 17:30
  • 1
    @Mario - this scheme makes password padding a bit more difficult as it allows 'pa$Sw0rd' but disallows 'pa$Sw0rd<<<###<<<###<<<###ThisIsLongPadding<<<###<<<###<<<###' even though the first one will probably be tested in the dictionary attack phase while latter probably doesn't (and it's also longer then 50 characters). – Maciej Piechotka Jun 26 '14 at 18:11
  • Indeed, "strong" password metres are defeated by humans because the whole range of possible passwords they afford is **never used**. However they are very painful in preventing you from creating easy-to-remember throw-away passwords for sites you don't trust and don't care about; in preventing you from reusing strong passwords which is better than nothing for certain accounts with no financial value; and in getting in the way of your own password creation strategies. – Steve Dodier-Lazaro Jun 26 '14 at 18:20
1

In addition to steve's answer, because having any method to the madness in your password makes it vulnerable, the best advice is to make it random and long. How long?

22 seems to be about right if its a random sampling of the 62 character alphabet: a-z, A-Z, 0-9.

And they should be unique from site to site.

But how do I remember all of these random, long, unique garblygoop passwords??? You don't. Use a password manager!

Community
  • 1
Andrew Hoffman
  • 1,997
  • 15
  • 17
  • You might remember long passwords... as long as they're pass phrases rather than passwords, you have a good memory and you use that long password very very often (or rather, you never not use it for long enough to forget it). However nobody convinced me yet that a long random password is actually usable in the same sense as a very basic secret. There are people who pretend to be looking at this issue but their experimental validations have a bunch of methodology issues. – Steve Dodier-Lazaro Jun 26 '14 at 18:26
  • That is my professional recommendation to people who actively care about their password strength. It provides excellent security on any site that at the bare minimum hashes once with a SHA1 hash. For a minimum password requirement strategy for people that don't care, it doesn't matter too much, they're going to make a weak password/passphrase regardless. Easy to remember passphrases are vulnerable to permutation dictionary attacks as well, but yeah they're better than a short string-digit password. – Andrew Hoffman Jun 26 '14 at 18:46
  • 1
    I believe (but this is merely dogmatic belief) that pass phrases of a word dictionary size S are better than passwords of a char dictionary size S, because there are many more words than there are characters (even when you force people to add hieroglyphs and the blood of a virgin as the joke says), but also because the space of permutations that you can remember is larger (since permutations are made in a space that is S times your average word length). This'd need to be challenged by looking at how people write passphrases though; are their choices of word predictable? – Steve Dodier-Lazaro Jun 26 '14 at 20:45