There is a long discussion on whether it's the responsibility of the user or the system administrator to deal with the strength of the password. Obviously, the password is a very private thing, but evidently, weak passwords jeopardize the entire organization and other user's data as well.

What are the ways of ensuring the user will pick a strong password and/or pick a password that is not one of the first tested passwords in a brute-force attack?

  • Using the same password is a horrible idea, the problem of course, even a 40 character password is horrible if its used for everything. At the end of the day who are you to say my short password is not secure enough for needs? One thing I have noticed is that every single site that ATTEMPTS to force me to use a secure password does not actually accept a secure password. One example is Chase.com would suggested a 8-20 character password. It refused my 20 character password when I created my account...I even think it said it wasn't strong enough. I should none of these sites even check entropy.
    – Ramhound
    Dec 7 '12 at 12:31
  • Related: security.stackexchange.com/questions/32222/…
    – Nemo
    Nov 8 '15 at 8:48

Education, threats and tools.

The first mitigation for security issues is to enlist users. You cannot obtain good security without their awareness anyway, so you might just as well ask for their help. Publish guidelines on how a password should be chosen.

To strengthen the previous point, pressure them a bit (just a tiny bit). Speak the fateful word: "responsible". Humans being humans, some will need the extra incentive; notably, taking care to explicitly spell out whose fault attacks will be, will emphasize the seriousness of the issue. People won't believe in the importance of the security issues if you, as server maintainer, do not do your homework. These small, thinly veiled threats will push the users into the slightly uncomfortable zone where they are alert. Don't overdo it ! You want users who comply, not users who fight your system.

At that point, help the users. The basic fact of password generation is that humans are no good at randomness. But randomness is what is needed for a password. Since this is a webapp, you have a trusted Web server -- "trusted" in the sense that the password is to ensure the safety of that server, so the server itself cannot be an enemy (it would make no sense). Thus, use that server: include a password generator. Something which will produce good passwords, accessible with one click.

The two facets of password generation are that the password must not be guessable, but it must be memorized nonetheless. By giving rules for password generation, you assume that the mnemonics by which the user will remember the password will match exactly the process by which the password was created. This is an artificial restriction. Consider the famous XKCD password generator: the generator is not about choosing four words which "make sense" together; instead, it is about selecting four words at random and then, only then, find a "meaning" for it (such as the ungulate mammal pondering electricity storage devices). This highlights how strong passwords are produced: use randomness, then train the brain to cope with the result.

A password generation scheme I am rather fond of goes thus: generate two letters, then two digits, then two letters, then two digits. To please inflexible application interfaces, make the first two letters lowercase, and the other two uppercase. The entropy of this generation process is 104*264, i.e. a bit above 232. 32 bits of entropy are not bad: it will take an average of more than two billion tries to break a password of that kind. This is enough for online security (it would take much too long for your server to "try out" that many passwords). On the other hand, I find that this random passwords are easy to remember. Try it ! You already remember phone numbers, which are numeric-only; the letters are great "anchors" for the mind, and make the memorization only easier. Here are five passwords of that kind, freshly generated (I did not choose them):


For each of them, I wage that you are already finding a simple way to "rebuild" it in your brain, as if you had created it in a witty way. But since they have been generated with real randomness, their entropy is intact.

  • You already remember phone numbers I don't. ;) +1 though, great answer.
    – user10211
    Dec 3 '12 at 12:25
  • 1
    @TerryChia You might not, otoh I not only memorize phone numbers; but also that of my preferred credit card to expedite online shopping (23 digits). And on the gripping hand, do you actually pull out your phone and look up your number in its phonebook every time you're asked what your number is? If not, it's just a question of to what degree you memorize phone numbers. Dec 3 '12 at 13:45
  • 2
    Virtual -1 for suggesting use of random passwords. They will be written down, guaranteed. Giving the user no control over their password is the #1 best way to alienate users and make them uncooperative in addition to making even good security people write down their password, or at least store it in a key keeper. Dec 3 '12 at 14:13
  • 1
    Heh - +1 to Dan for reminding me of my fyunch (click) ... I do think that younger generations don't memorise phone numbers like we did. Smartphones remove the need..
    – Rory Alsop
    Dec 3 '12 at 14:14
  • 2
    @AJHenderson: note that I never suggested enforcing a server-chosen password; merely to provide the password generation button. Also, writing down passwords, that's not that bad -- as long as the piece of paper is kept in a "secure" location (i.e. the user's wallet, not under the user's keyboard). Users usually apply better physical security on their wallet than logical security on their password. A wallet-stored password is an improvement. Dec 3 '12 at 14:27

There are a few ways I can think of.

Require certain character combinations

This is a commonly used technique. Require users to input a certain combination of characters like a mix of capitalized words, non-capitalized words, numbers and symbols. Enforce a minimum password length. Do not be overly restrictive though, as it might force users to mix combinations in an insecure manner.

Password1234 is no more secure than password.

This technique could also restrict strong passphrases. See: XKCD #936: Short complex password, or long dictionary passphrase?

Deny common passwords using a blacklist

Maintain a blacklist of commonly cracked passwords and do not allow the users to register using them. This could prove to be a sizable amount of work to maintain.

  • 2
    Simple entropy-like calculations work better than requiring specific character groups. For example, repeating a1! five times gives a long password that contains a letter, number and symbol, but isn't actually very strong. Deny anything that has a low amount of entropy, and rely on blacklists to cover anything bad passwords that would otherwise meet your statistical tests.
    – Polynomial
    Dec 3 '12 at 11:34
  • 1
    @Polynomial: if you have access to one million passwords from the same user, then I would agree. But you only have one password. Calculating entropy from one password is akin to predicting the issue of an election by asking one voter. Dec 3 '12 at 11:56
  • 1
    @ThomasPornin - I think what Polynomial is talking about is that something like a1!a1!a1!a1!a1! doesn't have enough entropy (randomness) within itself. IE - it's the same three letters repeated five times. Likewise, Password1234 could similarly fail an entropy test (dictionary test notwithstanding), due to things like the repeated s (depending on how trigger-happy your entropy detection is) and the sequential 1234.
    – Shauna
    Dec 3 '12 at 14:11
  • 1
    This is the best approach, though be very careful not to be overly restrictive based on the sensitivity of the information. I know I had a health insurance company that required an incredibly overly elaborate password that even my highest security passwords couldn't meet and my password ended up being a derivative of telling them where they could stick it (which while not very secure, the site didn't really have any information on it that required that kind of security). Dec 3 '12 at 14:15
  • 1
    @Polynomial What ThomasPornin is (correctly) pointing out is that you can't know the randomness of a single data point. How random is the number 8332? It's impossible to say without context. When people talk about password entropy, they typically mean the size of the keyspace as expressed as Shannon Entropy; that is, the amount of information contained in the password that can't be compressed out. It's a particularly bad metric, though.
    – tylerl
    Dec 3 '12 at 17:57

I'd also add that weak passwords can be significantly mitigated if there are good restrictions on login attempts. It isn't going to protect you if your hash file is lost and undetected, but at that point it is more of an administrator issue. The biggest concern for higher security stuff would be that passwords could be reused from other sites which could be compromised. Making a username that is not directly matchable to a user is a decent way around this. Even if I know that Bob Worker uses BobW0rker12345 for his facebook password, if I don't know Bob Worker's login credentials, then having access to his Facebook password doesn't help me.

Password complexity requirements can also help make sure that it can't easily be guessed, but also come with a variety of stupid user trick caveats such as people writing passwords down or becoming directly frustrated with your system and directly trying to fight against your system because it is making their life difficult, so you should always weight the risk vs reward for password complexity requirements. Sometimes it is truly necessary and if so, then it goes to the third and most critical point of user education.

Your users have to understand why the level of security is necessary and be willing participants. Ultimately, your users collectively are far more creative than you and they WILL do things you didn't expect that compromise security unless they understand the importance and are invested in it.

  • +1 for your users collectively are far more creative... Dec 4 '12 at 6:02

The answer should stronlgy depend on the purpose of the password.

Is something like a forum? Then don't annoy users by forcing them to replace the o in their default password by a 0. That's as far as they will go before simply abandoning your site. Feel free to notify them that their password sucks and that you won't take any responsibility, but don't force them to use the only complex password they can remember - that to their PayPal account...

Is it something like a shop? Then warn users about the weakness of their password and maybe have them confirm twice, including a "I am aware that my password is more likely to be cracked than others and I won't come to you crying about it when that happens" statement. But don't force them to use a password they can't remember - I'd argue a password manager should be standard, but it isn't, and your users shouldn't consider the password reset function as the default way to log in. Consider offering Two-factor authentication or OpenID instead.

Is it actually the web interface to launching a nuclear weapon or triggering the ISS life support systems? In that case, using a mere password authentication is a serious flaw in itself, though not as bad as actually connecting these things to the internet.


Entropy calculation.

A dictionary word, proper name or other member of the modern English language has, on average, about 1.5 bits of entropy per letter. To this, you can add a bit for each capital letter, a bit for each "leet" substitution (0 for o, 1 for i, 2 for q, 3 for e, 4 or @ for a, etc), 3 bits for each numeral digit in a prefix or suffix that is not in sequential order, and 4 bits for each punctuation mark not used as a substitution.

To calculate entropy automatically based on an entered password, I'd strip all leading and trailing numbers/symbols, split on capital letters and run what's left through a spell-checker to get the actual word(s).

Take the sum of all bits of entropy, and raise 2 to that power. That is how many brute-force guesses it would take to try all possibilities using a dictionary-based cracker. How fast it could happen depends on how fast your front door can process login attempts; I recommend password verification based on a slow hash (bcrypt) server-side coupled with a maximum number of login attempts, on top of whatever mechanism you use to secure password transmission from client to server.

Anyway, once you have a score and know what it means in terms of the length of an attack (honestly, if you see even 3 hours' worth of repetitive failed login attempts, there should be alarm bells going off), you can set thresholds for "weak", "normal", "strong" etc, and don't accept a "weak" password. Understand that due to Moore's law, today's strong password is tomorrow's weak password, and what takes a GPU-based cracker years could take a botnet or an intelligence agency days.

  • Password protection in itself is inherently insecure

  • The question cannot be easily answered without additional context. How strong a password needs to be depends on the value of the resource it is protecting. Therefore, to what extent an application should do anything about the strength of a password depends on what it is protecting (although, there is an issue of people who use the same password on multiple sites - see next point).

  • User education and awareness is critical. Lack of eduction and awareness will create resentment amongst your users if you force them to use passwords you consider very strong and they consider difficult to create or remember. Likewise, a mismatch between enforced strength and perceived value of what is being protected will cause resentment.

  • Consider the threat and how it may be realized. Brute force attacks rarely occur via an application interface. More often than not, they are applied to a bunch of passwords which have been stolen from the applicaiton's backend repository. There is no point in forcing users to enter strong passwords if they way you store and manage those passwords mean that someone is able to obtain them. Given time, enough CPU and memory and poor encryption algorithms, password strength becomes irrelevant.

All that aside, I think it is reasonable to reduce your exposure by enforcing strong passwords. I wouldn't go overboard. Enforce a minimum password length, mixture of upper/lowercase and inclusion of number and punctuation characters, but accept users will find/do things which will still compromise your attempts. Recognize that passwords are just inherently insecure when used as the sole method of authenticaiton and weight that up against the value of what is being protected. If the risk is still too high, then consider additional mechanisms, such as two factor authenticaiton.

This stuff is not measured in absolutes. There is no one size fits all solutions and password strength is not the only piece of the puzzle you need to consider. Look at how you store and manage passwords, consider where an attack is likely to come from, how you will be alerted to such an attack, how to get your users to adopt good practice, how to balance value and inconvenience of any security measure etc. and remember that this is not a do and forget process. This is something which needs to be reviewed and updated on a regular basis as technology, techniques and behaviour changes.


A better question may be: Why does my web-application requires passwords in the first place?

I don't have any passwords for any of my StackExchange accounts!

Depending on the application, tying it with another authentication service, or generating a pseudo-random password by default, might be the best approach.

If you generate a pseudo-random password, you might want it to be random enough, yet easy to remember.

There are a number of tools that generate passwords with consonants interchanged with vowels, potentially interchanged with a couple of numbers; such passwords are inherently strong for web-applications (since you can't brute-force a web-application undetected), yet they're easy-enough to remember, since they don't actually look totally random, but resemble some strange word or name.

An example of a good tool that generates such easy-to-remember, readable and pronounceable passwords is a console tool called pwgen.


  • that is not the question. forcing a user to use another service to login will limit me to those kind of users (not everyone have facebook,gmail,twitter) and the list of third parties could be very long. Also, This doesn't improve security. There have been accounts of hacking one account results in enabling access to others. Also, easy-to-remember for one is not easy to remember for others Dec 7 '12 at 10:51
  • If underlying email account that was used for registration with your service is compromised, then it would usually not matter whether you use passwords or passwordless authentication, since the attacker could simply reset the password. Also, this part of your reply makes no sense to me: "easy-to-remember for one is not easy to remember for others". What do you mean here? Do you disagree with the fact that fake words are easier to remember than completely random letters and numbers in random arrangement? Seems like you may already have made your mind, then.
    – cnst
    Dec 7 '12 at 18:39

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.