Enforce the use of different sets of characters for passwords?

[fluidistic]

Why do most websites enforce the use of different sets of characters when creating a password? This is less secure than choosing a password from different sets of characters uniformly randomly.

If we take an example of a 2 characters password and the 2 sets "letters" and "digits", if we use the good practice to maximize entropy by choosing uniformly randomly, then we have (26 + 10) ^2 = 1296 different passwords possible. Whereas if we follow the bad practice enforced by most websites, we have 26 x 10 = 260 possible passwords.
In the first case, we can fall into the bad luck to pick 2 digits, therefore falling into a single set category, containing only 10^2 = 100 passwords. Therefore there is approximately 8% chances to do worse than following what websites enforce.
There is 26 x 26 = 676 passwords that contains 2 letters, so about 52% chances to fall into a single category that provides better security than the one that is enforced upon us. This leaves about 40% chances we do equal than what is enforced upon us, with this simple example.

In more realistic examples, we are often limited to a few digits (<10) for banking stuff, to a low limit (<20) with few different sets of characters. In this latter case, following what is enforced is even worse than the simple example I described above. For larger passwords with more sets of different characters, I often let uniform randomness at play and many times (so a non negligible percentage) there is no character from several sets of characters. For example, the 40 characters long password generated doesn't contain lowercase letters, or digits. And it is better like this. Because the characters are chosen from a much larger set of characters than the one of lowercases.
We should not enforce the use of different sets of characters. At best, there could be a checker that one didn't pick a low entropy password by an extreme bad luck, but this would only happen if the password is too short anyway.

 

[Baluncore]

I would like to use an illogical phrase as a password.
Why is the number of characters, permitted in a password, so restricted?

 

[Rive]

Why do most websites enforce the use of different sets of characters when creating a password? This is less secure than choosing a password from different sets of characters uniformly randomly.

Because if possible, most people prefer to choose a meaningful phrase for a password, not something random.
So it's about to 'break up' phrases.

IMHO to ask why even a single use, risk-free registration requires a long, mixed, high security password these days is a better question...

 

[pbuk]

Why do most websites enforce the use of different sets of characters when creating a password? This is less secure than choosing a password from different sets of characters uniformly randomly.

Because if given the choice, many people would not choose a password from different sets of characters uniformly randomly, they would choose the name of a pet or their favourite sports team, or even 'password'.

There is 26 x 26 = 676 passwords that contains 2 letters, so about 52% chances to fall into a single category that provides better security than the one that is enforced upon us.

Increasing entropy by 52% is insignificant - it changes an attack time of 1 day to 36 hours whereas adding an extra character in [A-Za-z0-9] changes an attack time from 1 day to 2 months.

I would like to use an illogical phrase as a password.
Why is the number of characters, permitted in a password, so restricted?

Is it? Where? This is a sign of an outdated approach to security.

 

[fluidistic]

Because if given the choice, many people would not choose a password from different sets of characters uniformly randomly, they would choose the name of a pet or their favourite sports team, or even 'password'.

So instead of letting people use good practices, you force them to use a non optimal one for the sake of those who have no understanding of what they're doing. OK fine, this is a justification, but then there are better solutions. One of them is letting a modern entropy calculator check that the password is probably OK. Enforcing, instead of suggesting, a bad practice is not a solution IMO, but this is what is currently implemented.

Increasing entropy by 52% is insignificant - it changes an attack time of 1 day to 36 hours whereas adding an extra character in [A-Za-z0-9] changes an attack time from 1 day to 2 months.

Not sure where you get that entropy increases by 52%. And I was just focusing on a simple, albeit non realistic case.

 

[jack action]

It is even worse than that:

When most people are asked to put a number in their password, they will put a 1 or their year of birth at the end. When asked to include a symbol, many will use an exclamation mark.

People who have brains can find the rules created by people using their similar brains to create rules to make passwords. It is the same machine. You thought of it, someone else can too.

When half the rules are public knowledge (restrictions), you are making it even easier.

The only good password must be random as much as possible. The method I like to use is having a 50 alphanumeric, lowercase, password. This gives you more than 256 bits of entropy, which is believed to be physically impossible to break by brute-force attack. But if you have at least 20 alphanumeric, lowercase characters, you should be fine. You should use a password manager and - if you ever have to enter it manually - a simple terminal can do the job easily. (No need for uppercase or hard-to-find characters that could be missing on another language keyboard, etc.)

@fluidistic , every thought you may have about the ineffectiveness of enforced password rules has already been thought of before:

Though increasing the minimum password length, in theory, would increase the possible password combinations, in practice, it actually makes brute-forcing easier, since we are now artificially establishing a floor to begin our password guesses. Take a twelve-character password minimum, for example. In theory, this would bring the possible password combinations to 26ˆ12. However, there is a huge gotcha in that thinking because, in practice, most users create passwords that meet the minimum – twelve characters exactly. Therefore, to brute force this, we only have to look at passwords that are exactly twelve characters long vs. passwords that are more or less than twelve characters, which is a much smaller search space and effectively decreases the overall strength.

Similar things happen by mandating additional character classes, numbers, and symbols. As an example, if we include all common character classes (both lower- and upper-case letters, numbers 0-9, and the standard ASCI keyboard symbols) we have 96 possibilities for each position. So, for a twelve-character password, we end up with 96ˆ12 password combinations. However, in the real world, we can often simplify this based on English dictionary wordlists, password trends, and other requirements.

Congratulations, we’ve now forced everyone to use Ahh00000gah! As a password! It’s memorable, 12 characters, and includes all of the character classes we require.

Let’s look at the password requirements from one unnamed secure messaging portal:

8-15 Characters

At least one capital letter

At least one lower case letter

At least one number

At least one special character from a reduced set of 30 characters

In an ideal world, this should give us 92ˆ15 possibilities. But that’s not the whole story. Because the password must be at least 8 characters, the search space is effectively reduced to 92ˆ15 - 92ˆ8 possibilities, a significant reduction. You’ll also notice that, for whatever reason, they reduced the allowed symbols or special characters by four (we can maybe speculate they didn’t know how to escape those characters to prevent something like SQL injection). Even that reduced set doesn’t tell the whole story though, as four of those seven positions must be from specific character classes leaving only three positions for the full possible character set. So, while the math isn’t exact and is greatly simplified for clarity, we now have a total set of passwords that is closer to 2.3*10^29, a reduction of ~5*10^28 from our starting set of 92^15 or 2.89*10^29. If you’re really curious about the math, grab a beer and work your way through [2].

It looks like everyone can keep using Ahh00000gah! As a password though. Please don’t though, that password is not secure at all, and well now everybody knows it.

With some simplifications, we now added security in the form of complexity and intended to increase password strength to 92ˆ15 and ended up with a lower effective length ~2.31*10^29; experimentally, we’ve seen a reduction of about 20% in possible password combinations with these rules. 2.31 * 10^29 is still a really huge number, but it’s a smaller set of passwords then we were trying achieve. If we assume our same one guess per second as above, we’re still in the realm of a “lifetime”. By forcing arbitrary constraints on passwords, we added complexity, annoyed the users, and resulted in passwords that are even less secure than we had before!

Being that we as an industry have pushed the concepts of not writing passwords down, having memorable passwords, etc. we can make some additional assumptions about how users will create passwords. Namely, we can assume most passwords will be based in parts of the English language, and have recognizable patterns further decreasing that 9 days.

We can expect users to create passwords like Moneyˆ(1/2)evil (Exactly 15 characters, uses all of the character classes, easy to remember, etc.). By assuming passwords like this we can essentially use permutations of word lists, with some punctuation, and “leet” speak replacements to further reduce our search space. Similarly, if we force passwords to be changed every 60 days, we can expect most passwords to then take on some form of a pattern like:

Bank_balance000 => Bank_balance001 => Bank_balance002

Which again only serves to simplify the search space and reduce the total permutations of passwords that need to be checked.

 

[Rive]

ineffectiveness of enforced password rules

...and by throwing in that even just an average IT environment would require memorizing a few kb of supposedly random garbage (based on my personal not-so-wide registration and PW list) , we can conclude that most user will cheat.

 

[FactChecker]

It's my understanding that any good, LONG password with restrictions is much harder to crack than a short one with no restrictions.
A related gripe of mine is that the allowable special characters and other rules are not standardized. So a password manager that automatically generates long, random passwords usually generates rejected passwords. I usually have to manually modify their generated password.

 

[jack action]

any good, LONG password with restrictions

Define "good".

If your definition of "good" is "randomly generated", then the restrictions are useless and just annoying noise. A good - randomly generated - SHORT password is most likely better than a LONG "bad" password. Even a 23-character password such as Anonymoushacker1alt8214 has already been found. There is even a lovely 112-character password on the same list - ****YOUFUCKthis98989!!!!fourtwentyPassw0rdBitch.comyo__!@!@$%$%@%^&thiswillneverbemypasswordforanythingsofuckyou - that will appear partially censured here. I think the creator of that password thought he was really smart. (Pretty sure he's a "he", most likely in his teens )

 

[vela]

So instead of letting people use good practices, you force them to use a non optimal one for the sake of those who have no understanding of what they're doing. OK fine, this is a justification, but then there are better solutions. One of them is letting a modern entropy calculator check that the password is probably OK. Enforcing, instead of suggesting, a bad practice is not a solution IMO, but this is what is currently implemented.

From a practical standpoint, all you care about is generating a password that will take a long time to crack. Even if you're using supposedly poor practices, if the resulting password takes 10 billion years to crack, who cares?

The problem with entropy calculators is that they're only as good as the assumptions they're based on. As @jack action has noted,

People who have brains can find the rules created by people using their similar brains to create rules to make passwords. It is the same machine. You thought of it, someone else can too.

Most calculators I suspect don't even consider complications like this. They just calculate the size of a sample space based on the number of characters allowed and the length of the password. Maybe they rule out really dumb ones, like "password1!" or your name. Even so, a long password based on a pattern is much weaker in reality than an entropy calculator would probably suggest.

 

[FactChecker]

Define "good".

If your definition of "good" is "randomly generated", then the restrictions are useless and just annoying noise. A good - randomly generated - SHORT password is most likely better than a LONG "bad" password. Even a 23-character password such as Anonymoushacker1alt8214 has already been found. There is even a lovely 112-character password on the same list - ****YOUFUCKthis98989!!!!fourtwentyPassw0rdBitch.comyo__!@!@$%$%@%^&thiswillneverbemypasswordforanythingsofuckyou - that will appear partially censured here. I think the creator of that password thought he was really smart. (Pretty sure he's a "he", most likely in his teens )

Wow! I'm amazed that that password was found!
It's also necessary to define "short". Most password generators make it easy to make 15 to 20 character random passwords. I would not call that short even though it is a lot shorter than the ones you list that were broken.
I have two major problems with the password generators in password managers. The problem of no standardization of the allowable special characters is one problem. The other problem is that I would never be able to remember any password if I do not have the password manager handy.

 

[Vanadium 50]

There is a difference between "theoretically good" and "practically good" passwords. Most users of computers - and cell phones are computers - are not security experts. Moving them from qwerty to i&Qn7aiZ is a huge step forward. Going from i&Qn7aiZ to #nV8Sottb8jEI9Xc!7midi!gP is better, but qualitatively you've gotten most of the improvement by stopping using qwerty.

I attended a talk on computer security and was blown away by a statistic (which I could reference it) - 40% of passwords with the usual enforced requirements are of the same form: a six letter dictionary word with the first digit capitalized, a digit, and an exclamation point. Is Qwerty7! better than qwerty? Well, maybe a little.

For that matter, is P@ssw0rd better than password? Maybe a little.

 

[jack action]

Is Qwerty7! better than qwerty? Well, maybe a little.

For that matter, is P@ssw0rd better than password? Maybe a little.

They are not. Especially if there are publicly known rules enforcing uppercase-lowercase-number-special-character, as you know that most passwords will end with "1!", effectively having two useless characters.

It just gives a false sense of security.