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?
The tests for any policy are:
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).
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:
01234567890123456789
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.
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.
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:
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.
