22

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?

Celeritas
  • 10,089
  • 22
  • 79
  • 144
  • 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 00:38

4 Answers4

13

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)

Community
  • 1
mgibsonbr
  • 2,925
  • 2
  • 21
  • 35
  • No password complexity-related question can be answered without mentioning the XKCD #936. – KeithS Feb 01 '13 at 20:09
  • What's wrong with writing down passwords? Even if my webcam is compromised, a remote hacker is unlikely to read my hand-written notes. And if someone has physically broken into an office then we have bigger problems. – gerrit Feb 10 '20 at 10:38
  • @gerrit Depending on your work, the data might be orders of magnitude more valuable than any stolen hardware. One of my old customers, for instance - a school - was actually robbed a few years ago, and had some of its computers taken. It was bad, but not as bad as if, say, the personal info of hundreds of children [stored offsite] were also leaked in the process... What I'm trying to say is that it's not *always* bad to write down passwords, but sometimes it is, and the likelihood of someone doing it anyway increases the more inconvenient the password system is for them. – mgibsonbr Feb 10 '20 at 17:19
12

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

NULLZ
  • 11,446
  • 18
  • 80
  • 111
  • 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 00: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](http://www.schneier.com/blog/archives/2010/11/changing_passwo.html) to change the password regularly) – mgibsonbr Jan 29 '13 at 02:18
  • 1
    Has the recommendations around this changed in recent years? I see things like ["The problems with forcing regular password expiry"](https://www.cesg.gov.uk/articles/problems-forcing-regular-password-expiry) and the [well-known Password Strength XKCD](https://www.explainxkcd.com/wiki/index.php/936:_Password_Strength) 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 01 '16 at 15:22
  • 7
    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 06 '16 at 10:30
11

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.

Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
1

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
Akam
  • 1,337
  • 3
  • 15
  • 24