I'm making a website and I'm deciding on the password policy. What does make a good password? I really have no idea. I guess passwords should be at least 6 characters long.

EDIT: are there any recommendations on how "complex" the password should be? For example require 2 digits 2 grammar characters and the remainder of the password can be anything?

  • 4
    as a website administrator you should also implement some defense against brute-force and dictionary attacks . 1000 login-attempts per minute is far away from any human mistakes in the password input. – Jan Koester Jan 29 '13 at 0:38

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

  • What difference does it make if the user changes their password back to one they had a few months ago? – Celeritas Jan 29 '13 at 0:47
  • @Celeritas Bacause that defeats the purpose of changing passwords. If you change, it's because you think it was compromised or there are reasonable odds that it migth be compromised. By reusing an old password, anyone who still knows it would be able to log in. (note that, for most sites, it's not really necessary to change the password regularly) – mgibsonbr Jan 29 '13 at 2:18
  • 1
    Has the recommendations around this changed in recent years? I see things like "The problems with forcing regular password expiry" and the well-known Password Strength XKCD which gives me some hesitance to know what modern password policies should be. – mkobit Apr 19 '16 at 14:09
  • I concur with the passphrase suggestion. Passphrases are super-easy to remember, and are extra long. Even if it contains only dictionary words (say 4-5 words) and it's not a sentence, the entropy is quite high. A 30000 word pool with 4 chosen at random has a space of ~ 59.5 bits, which would take about ~19 thousand years to guess at 1kk guesses/sec. – Desthro Jun 1 '16 at 15:22
  • 5
    this is no longer recommended best practices of owasp and that linked page has been deleted due to that page not reflecting the latest research. The latest research suggests that adding password complexity requirements like upper case/numbers/symbols cause users to make easy to predict changes and cause them to create simpler passwords overall due to being harder to remember. – rdans Jun 6 '16 at 10:30

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)

  • No password complexity-related question can be answered without mentioning the XKCD #936. – KeithS Feb 1 '13 at 20:09

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.


You talked about password policy which includes also password change duration. How to measure good password?

  • Strong
  • Memorable

Strong property has inverse relation with memorable

Then, its your effort to decide on them, which one is more critical? then you set high priority to that one, but consider that each password must match some rules (minimum requirement):

  • length: between (6-12)
  • pattern: [a-Z][0-9][special charactors]
  • password must at least contain 4 different characters form each group (if length =6)
  • password must at least contain 6 different characters form each group (if length =8)
  • Password Change Duration (Expire policy): each three months for example
  • Account Lock out: number of allowed invalid attempt: 3, then, account must be locked and unlocked by administrator

I know it's been 3 years but this needs a refresh.

As long as you've set up enough connection protection (block after 3 wrong attempts for example) you're safe. As long as the database doesn't leak. But if the database is hacked, you're almost dead.

Take this password Lov3t©cöde looks cool, doesn't it? It contains:

  • Lower case char;
  • Upper case char;
  • Numbers;
  • Special char.

And is 10 characters long. Looks great. But with nowadays GPU power and a few thousand dollars, you can break it within a week. You don't trust me? Try it.

What I would recommend is a passphrase. Something that you can remember, because what's the point it you have to write it down on a text file?

Take an easy sentence:

I eat chocolate at night!

add entropy to it:


Congratulations! You now have a 22 long password that would take around 1.04 hundred million trillion centuries to break, which you can remember! (Because the complexity space is 95^22. If you allow a set of 33 special char, which makes ~3.27 x 10^43. Assuming one hundred trillion guesses per second, it will take my 1.04 hundred million trillion centuries.)

Great, what could be better? Allow users to connect through them google/facebook/whatever accounts. Then you'll never have to worry about your password policy.

  • 1
    Any reasonable password policy will, by extension, allow passphrases as well. – a CVn Jun 1 '16 at 17:19
  • I also call shenigans on your "1.04 hundred million trillion centuries to break" claim. At the very least, show us the math behind that claim. – a CVn Jun 1 '16 at 17:20
  • 1
    Complexity space is 95^22, if you allow a set of 33 special char, which makes ~3.27 x 10^43. Assuming one hundred trillion guesses per second, it will take my 1.04 hundred million trillion centuries. – Thomas Ayoub Jun 1 '16 at 18:29
  • 2
    The search space is 95^22 if and only if every character was independently selected in a random, uniformly distributed fashion, from a 95-character set. Neither is true in your example. Besides its obvious resemblance to English, with all of what that means in terms of bigrams, trigrams, the possibility of dictionary word searches, etc., your example only demonstrates 13 distinct characters, two of which occur three times each and another five occur two times each: not particularly uniform. It's effectively 4 English words with random punctuation and a random suffix: not very random. – a CVn Jun 1 '16 at 19:32
  • A process of replacing specific characters with other characters does not measurably increase entropy. Entropy is a byproduct of the randomness of the selection process, not a function of increasing the character space alone. – Xander Jun 1 '16 at 20:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.