I'm wondering, would it be clearer to declare a company wide requirement with regard to password theoretical entropy, rather than the usual "at least one big letter, and a small latter, and special character..."

Thus if we target a reasonable entropy level for humans to remember, say 60-bits, then calculate the entropy.

This can be calculated dynamically and locally and give user feedback as needed.

Is this not a better, language/region agnostic way to do a password policy?

  • 16
    The only problem is getting the average person to understand it.
    – schroeder
    Commented Jun 2, 2020 at 12:30
  • 8
    How do you define "better"?
    – schroeder
    Commented Jun 2, 2020 at 12:32
  • 17
    It depends on the level of security you would like to achieve. Purely looking at the entropy also allows common passwords such as: 'Password1234' (50.8 bits) and 'MyPassword101' (58.7 bits). Commented Jun 2, 2020 at 12:36
  • 10
    @roy.stultiens No, it doesn't, because passwords do not have entropy. Password generation methods have entropy, and any generation method with 50+ bits is extraordinarily unlikely to produce those passwords. If a generation method has 50 bits of entropy, that means (to first approximation) that there are at least 2^50 passwords it could have selected from.
    – Ray
    Commented Jun 3, 2020 at 13:49
  • 1
    @Ray, usually the cracker does not know the generation method, in which case the entropy with respect to the cracking method, basically the probability they'll try that password, is more interesting. Of course since any cracking method will probably try those two examples in the first thousand or so, their entropy is 8 bits give or take.
    – Jan Hudec
    Commented Jun 3, 2020 at 19:01

5 Answers 5


The tests for any policy are:

  • people know about it
  • people understand it
  • people know if they are complying with it
  • people know how to comply with it

Your approach is about 2 out of 4 on that scale for the average user.

The better option is to demand randomly generated passwords. That's easy to understand, easy to implement, and easy to provide processes and tools for ("just use this password manager").

With your approach, you are basically trying to get people to be their own random generator. This is going to result in a lot of trial and error as people try to figure out what password will pass the test. This will result in frustration and confusion.

But that's assuming that you are writing a policy for the average user and assuming your calculation of entropy is valid (which seems beside the point of your question right now, and I have some serious reservations about it).

  • 6
    Good point on how this basically asks people to ask like random number generators. One (of the many) reasons why people are so bad at passwords is because we are, inherently, terrible random number generators. Commented Jun 2, 2020 at 12:39
  • It is not always possible (or rather - practical) to use random passwords. An example is Windows login. In that case a xkcd-like passphrase is better. Otherwise yes - password managers.
    – WoJ
    Commented Jun 3, 2020 at 12:41
  • 2
    @WoJ "random" does not have to mean "random string". "Random 3 words" is a standard by the UK's NCSC.
    – schroeder
    Commented Jun 3, 2020 at 13:29
  • 4
    @WoJ And to follow up schroeder's comment, the xkcd method you mention specifically assumes that the words are all selected uniformly at random. The entropy's way lower if you use passphrases that mean something.
    – Ray
    Commented Jun 3, 2020 at 14:09
  • 1
    @schroeder: yes, my comment was in the context of The better option is to demand randomly generated passwords. (...) ("just use this password manager") The result from a password manager will not be a word-based passphrase (and now that I think of it - it is something which is missing in the one(s) I use(d).
    – WoJ
    Commented Jun 3, 2020 at 15:10

The fundamental issue is that entropy can only be estimated from the password itself, and that estimate can be very very wrong. The entropy is determined by the password generation method. You can't measure the entropy of the method from a single password.

Let's look at a practical example. I find it easiest to memorize very long passwords generated from a small password space, so I'm going to use numbers only and make it very long. Your algorithm looks at my password, sees that it only contains numbers (aka character set size is 10) and that it is 20 characters long. This gives it an entropy of:

log2(10^20) = 66.4

It passes your test! However let's stop and look at the password:


Hmmm... turns out that the actual entropy is pretty much zero.

I could get a lot more technical but in this case I think it's better to keep the answer simple. I believe this example should provide a sufficient answer to your question.

  • 1
    thank you, upvoted! I am mandating that people choose a random password, but I agree that's an ask for the average user.
    – Woodstock
    Commented Jun 2, 2020 at 13:48
  • 2
    If you mandate that then perhaps you might as well make your system choose the random password for them. If you do that then of course you will control how much entropy goes in to it.
    – bdsl
    Commented Jun 3, 2020 at 11:50
  • I found that a good option is to use a password manager such as KeePass and let it generate passwords (and store them, of course.) By using cloud storage (my own server, encrypted password database) it is possible to access passwords from anywhere and have them automatically entered into login forms when needed. Commented Jun 3, 2020 at 12:31
  • 2
    Actually, the entropy is determined by the method that will be used to crack it, which may or may not be related to the one used to generate it.
    – Jan Hudec
    Commented Jun 3, 2020 at 19:04
  • 3
    @ConorMancone But what matters, at least much of the time, is the method that will be used to crack the password. The length of time that a password cracker will take to find your password depends on your password and the cracker, but not the method that was used to generate the password. For that matter, the age printed on your driver's license is what determines whether or not you can buy beer. :) What the password generation method does, of course, is provide a practical guarantee that a password will take at least such-and-such many attempts to crack. Commented Jun 4, 2020 at 1:27

A key thing to understand when selecting a password policy (or a password) is that entropy isn't a property of the password. It's a property of the method used to generate it. More generally, it's a property of probability distributions that tells us roughly how much additional information you would need to uniquely identify an element drawn from that distribution if you know what the distribution is. I go into a bit more detail in a previous answer if you're interested, but for passwords, this roughly means that if there are 2^n passwords that you might have generated, you have an entropy of n.

If the users generate their own passwords, you can't know what method they used. You can only set policies that make it more likely that the users will select a method that has high entropy. When doing so, you should keep in mind that users will generally find the laziest way of complying with a policy, which is why requiring that a password must contain capital letters and numbers is basically the same as requiring that the first letter be capitalized and that there be a single digit at the end.

The best password policy I've seen is Stanford's, which makes the special character requirements less onerous the longer the password is, to encourage the use of long passphrases instead of Password1$. If the password contains fewer than 12 characters, it requires every sort of character type. This restriction is relaxed as length increases, and once the password contains at least 20 characters, there are no additional restrictions. (There is also no upper bound for password length. Nothing is more annoying than a password policy that forces me to use short passwords in the name of security.) It then suggests randomly selecting 4 words as an easy way to get passwords that long, which is a password generation method with high entropy.

Under this policy, the good approach is also the laziest one, which means the users might actually do it.

Stanford Password Policy

  • 1
    @Woodstock You might also find DiceWare interesting. I personally use their method but with some of the EFF word lists (linked at the bottom of that page) Commented Jun 3, 2020 at 18:34
  • 1
    I like that Stanford approach. Does anyone know how they implement it? I know how to set length minimums and complexity requirements (essentially just complex or not-complex) in Active Directory for Windows accounts, but I don't know how I would go about implementing the staggered requirements.
    – Doug Deden
    Commented Jun 3, 2020 at 21:47
  • 2
    I think the presentation of this password policy to a normal user would lead to an inherently unsafe adoption of it by users. The sample password only consists of nouns and an average user is unlikely to choose between more than 500 different nouns when asked for some. So you just end up with no more than 60 billion different passwords which is still pretty easy to brute force once hashes are leaked. And I think the 500 nouns are still vastly exagerated because a normal user would for example just look around to find some nouns to use. Commented Jun 4, 2020 at 6:14
  • 2
    @SpaceTrucker:Well, 60 billion is about 37 bit of entropy (assuming each PW is equally likely). That's not that bad for a user-generated password...
    – sleske
    Commented Jun 4, 2020 at 12:35
  • 2
    @ConorMancone If there apparently are infographics out there that recommend to chose 4 nouns as best practice, then it's not unreasonable for an attacker to think that users will do exactly that.
    – kapex
    Commented Jun 5, 2020 at 14:02

I actually did this once upon a time with a few hundred users.

I estimated entropy based on the approximate alphabet size they used, where common dictionary words (taken from an English dictionary) counted as one "letter" each, and unknown words were divided into lower alpha, upper alpha, numbers, symbols, whitespace, etc. There were a few other common patterns it would identify which I won't go into the details of since it's not relevant.

If the calculated entropy was too low, the password was rejected and the user was shown some hints on how to improve it. There was certainly room for improvement but it worked very well for filtering out clearly weak passwords.

The problem was that the users hated it because it was difficult to understand (in particular it was difficult for them to make a weak password strong enough to use without making it really long).

Instead, these days, I would recommend enforcing only a minimum length, but checking user passwords against a database of known-breached passwords (e.g. https://haveibeenpwned.com/Passwords) and warning the user if their password is found.

It's tempting to block passwords which you know are bad, but if a user won't listen to a warning, it's because they don't care about the account anyway. If you force those users to pick a harder password, they're likely to compromise it some other way (e.g. by writing it on a post-it note on their monitor).

Finally, please consider whether you even need passwords at all. We're long past the days when every web service has its own login. There are a large number of single-sign-on services which you can integrate with to offload login management and make things easier for your users (as well as offering MFA, etc.), and for the more secure things using certificates is better security anyway (browser support for MTLS is pretty good now!)


rather than the usual "at least one big letter, and a small latter, and special character..."

Any policy that contains those requirements in 2020 is broken and needs to be revoked.(*)

The main things that regular users need to know about passwords are:

  • it should be long (10-12 characters recommended)
  • it should not be guessable (not "password" or "1234567890" or your name, birthday, etc. etc.)

on the IT-level, you should have a blacklist (the most common 1000 passwords or such).

(*) complexity rules are wrong. In almost every case, they make passwords easier to compromise. Don't use them. Seriously, don't. It's not the 1980s anymore.

  • @Mark I mean to count each pattern as equivalent to 1 character long. I'll re-post my comment to clarify this.
    – Cœur
    Commented Jun 5, 2020 at 4:40
  • Instead of a 1000 passwords blacklist, better have a 1000 subpatterns greylist, where each part of your password that matches "1234", "9999", "abcd", "qwerty", "pass", "word", ... will only count for a length of 1.
    – Cœur
    Commented Jun 5, 2020 at 4:43
  • @Cœur it's not a random blacklist, it's "the most common 1000 passwords". The reason I definitely recommend to blacklist those is that people actually use them, that's why they're on that list. And brute force tools use those lists. You definitely don't want someone has a password that any automated attack will definitely try, and early on.
    – Tom
    Commented Jun 5, 2020 at 4:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .