what are good requirements for a password

Bruce Schneier has written a nice essay about the subject, I suggest taking a look at that. In a nutshell:

  • Most users tend to use similar patterns for their passwords, and there are tools which are pretty good at guessing them (up to 65% success rates).

    • This pattern, as satirized here, consists of using a dictionary word (common or not) with some letters substituted according to common rules (such as 4 for A), followed by (or more rarely prefixed by) a simple affix (usually numeric).

    • The "danger" of such passwords is that they provide an illusion of complexity and thus security, while in fact they are relatively easy to crack (assuming an off-line attacker).

  • Passwords that contain biographical data (such as names, addresses, ZIP codes) are substantially easier to crack, so users should be discouraged from using them.

  • Very short passwords (4 characters or less) are also susceptible to exhaustive searches.

  • A good password, thus, should have reasonable length (8 characters as reccomended by OWASP might be ok, but in principle the longer the better) and not follow an easily recognizable pattern.

    • Alternatively, it could follow a pattern, but one that can not be easily replicated. An example would be thinking in a sentence, and creating a password from the first letters of each word in that sentence.

    • Another option (also suggested in the essay, though personally I disagree with it) is putting the affix (the numeric sequence) in the middle of the root (the word), or using two words joined together with the affix.

The most important of it all IMHO is not having a "maximum password length" or, if unavoidable, to leave that maximum at a very high value (such as 64 characters). Since you won't be storing the password itself, instead storing a secure hash of it, the length shouldn't affect your back-end design.

(Also don't try to "force" too much password complexity, or your users will begin to actively fight you - by writing down their passwords for instance)


To Quote OWASP's best practices:

Password length Password length considers the minimum and maximum length of characters comprising the password of your users. For ease of changing this length, its implementation can be configurable possibly using a properties file or xml configuration file.

Minimum length. Passwords should be at least eight (8) characters long. Combining this length with complexity makes a password difficult to guess and/or brute force.

In addition:

Password Complexity Password characters should be a combination of alphanumeric characters. Alphanumeric characters consist of letters, numbers, punctuation marks, mathematical and other conventional symbols. See implementation below for the exact characters referred to. For change password functionality, if possible, keep a history of old passwords hashes used. You should not store the actual passwords to protect against brute forcing if the database file is compromised. In this way, the user cannot change to a password that was used a couple of months back.

Just as importantly is how is the password stored? OWASP also has a number of recommendations on how to store password hashes securely. For more info read here

OWASP has a lot of good recommendations on how to deal with passwords and login/password reset forms. I thoroughly advise that you read through these and learn as much as you can.

Hope that helps!

Source: https://www.owasp.org/index.php/Password_length_%26_complexity#Best_practices


A password is only as strong as it is random. You cannot test for randomness of a password invented by a user in his brain, because randomness is a property of the generation process, not of the result. Your Web site will see only the result.

However, you can exclude passwords which are too short because short passwords are amenable to a very primitive exhaustive search, which means trying all combinations of letters up to a certain length. The main risk you must avoid is to antagonize users: passwords will be only as strong as the user chooses so, therefore you must make him a voluntary contributor to the site policy. The user, by himself, is not very interested in the site security. He enters the password because he has to (the site enforces a password entry), but he sees the password as a hindrance: he did not came to the site to enter a password, but to access whatever pages the site contains.

This boils down to the following recommendations:

  • Enforce a minimal password length of 8 characters. Not much more than that; but people are accustomed to entering 8-character passwords. If you ask for more, users will protest (and they protest by choosing "witty" passwords, which are not strong at all).

  • You may require a mixture of letters and digits. But don't overdo it. Letters and digits are fine; don't enforce uppercase/lowercase mix or punctuation: these are noticeably harder to type on smartphones and tablets.

  • Provide an optional password generator. Since human minds are not good at generating randomness, use the computer. But be careful not to make the generator mandatory: the user must see it as an helpful tool, not an unavoidable regulation. Therefore, provide a button "generate a good password" which generates a sequence of lowercase letters and digits (not an overly long one, mind you; 8 characters).

  • Publish guidelines which explain what a good password should be (i.e. random). Users love to feel empowered. Also, warn them about usability issues with regards to non-ASCII letters: accents, non-latin characters... will make their life much harder if they use them.

Tags:

Passwords