Does having a minimum number of digits improve password security?

Question

Some password systems will enforce at least X of a type of character - a common one I see is 'minimum 3 numeric characters'. As far as I understand, simply allowing certain character classes, like numerics, greatly increases the password space (e.g. (26*2)+10 possibilities for each case-sensitive alphanumeric character vs (26*2) for only alphabetic), so I don't see how having a minimum 3 digits does anything to improve password security/entropy.

My guess is that it's simply there to enforce some variety in the passwords so that users don't just use plain dictionary words.

Is my thinking correct? Are passwordABC and password123 not equally (un)reliable when the available character set is the same? (These contrived examples would probably be tried and found early by any attack, of course)

Or is there some technical reason why a minimum of X digits, special chars, whatever is a good policy?

Answer 1

The security of the password is not really about what the users are allowed to choose, but what the users actually choose on average.

The attacker tries to guess the password that the user chose, and he will do so by trying most probable passwords first. "Most probable" here designates a kind of psychological study that the attacker performs; in plain words, this means that the attacker will try names of famous soccer/baseball/hockey players because many users, left to their own devices, use these names as password.

The ideal user selects his password totally at random, with uniform probability over the space of possible passwords (i.e. all passwords that can be typed in and that the machine will accept). Most users won't do that, though. Even if they can use digits in their passwords, they will prefer not to use digits, if given the choice; because users, like everybody else, try to maximize their own comfort and efficiency, so they want passwords which are easy to type and easy to remember. A full-alphabetic password is easier to remember than a mixed letters-numbers password, and also easier to type, especially on smartphones (e.g. the basic Android visual keyboard shows letters and numbers on separate screens).

A constraint on a minimal number of digits is an attempt at making the users more random: it prevents them from using full-alphabetic passwords, because, when technically allowed to do so, users turn out to rely on very low entropy passwords (the ones which are easy to guess). By enforcing the inclusion of some digits, a sysadmin can push the users (slightly) out of their comfort zone, and force them to choose a password where a simple soccer player name is not a valid password.

Done with moderation and taste, this increases security by making passwords, on average, less guessable. Don't put too much hope in it, though: many users will add "111" at the end of their password, and be done with it. The attacker knows that, too. Moreover, the more constraints you add, the more likely is the user to become an enemy. People don't like to be pushed out of their comfort zone. If you shove them too much, they will react quite creatively, for instance by writing done passwords on a piece of paper (hidden, as per immemorial Tradition, under the keyboard -- and the attacker knows that, of course). The users cannot really be blamed for that, but the net effect is that security can decrease when well-intentioned constraints are enforced.

Answer 2

On the topic of non-alphabetic characters in passwords, there is a famous XKCD comic. Do also read the follow-up thread on this site. Beware that some of the answers there miss the point; I especially recommend the answers by Thomas Pornin, AviD and Mike Hamburg.

)

That's only one side of the coin, however. Most users don't try for a hard-to-guess password, they prefer to stick to something memorable, like the name of their first child. Forcing them to have a digit does add a couple of bits of entropy: sure, a lot will append 1, but some will use their date of birth. Users who type on a mobile keyboard that requires a mode switch between letters and digits are especially likely to put the digit(s) at the end.

Requiring punctuation is more likely to add entropy, by the way. While a . at the end is an “obvious” punctuation character, some users will pick a two-word passphrase with a punctuation in between.

There is also a security theater aspect: if you document in your security policy that passwords must have a minimum of X characters including 1 digit and 1 uppercase letter, it looks like you're doing something to improve security. Even if there are far better methods with all-lowercase passwords.

Answer 3

You are right in that the goal of forcing users to have a number in a password increases the character set and therefore the cryptographic strength, same as enforcing capitals and special characters. I think enforcing 3 digits in a password is counter-productive as most users will simply tack 3 numbers onto the end of a password to keep things simple. If most passwords are passw123 or something567 it actually reduces the complexity by introducing a pattern.

Answer 4

As a user there are two rules to password use:

1). Never re-use the same password with different entities (e.g., don't use the same password at your online bank as a free webforum set up by some anonymous individual). Any site potentially logs passwords in plaintext (even passwords for other sites accidentally typed) and potentially could use those passwords to attack users on other sites. [1].

2). Pick high-entropy passwords/passphrases (preferably randomly generated and only slightly modified) that will not be found in a dictionary attack or in any list of common passwords.

A system where users locally store an passphrase-protected encrypted list of randomly generated passwords synced between all your computers is a great solution, but you can't expect most users to be doing this.

As a developer setting password rules for a system its a balancing act. Stricter rules generally mean a more difficult user experience (UX). If your rules are especially strict, users will circumvent your rules somehow. They'll write it down by their computer, save it in plain-text on their desktop, or stop using your service, or complain incessantly to higher-ups, or use the password reset mechanism every time to login (which may end up being a much weaker link). Maybe you require a number in their password, they take a common dictionary word and just append a 1 to the end. You require passwords to be changed every three months and not reused, and the end user rotates their password to be Spring2012, Summer2012.

Conversely not having any rules means you will find many idiot users who will choose a password that's in a list of the top 100/1000 password lists.

Custom rules are nice, as you can set a bare minimum for length/complexity and additionally may prevent password reuse if your rules are quite particular (e.g., no special symbols; but at least two numbers and one upper/lowercase letters). However, you should make sure your custom rules do not exclude strong passphrases, which are a good way to achieve memorable high entropy passwords. Also, invalidating common, weak passwords may help secure your application. E.g., if you don't allow a user to set a password that is a dictionary word plus a number at the end, or a password from a common password list, that may strengthen security. (Though again an attacker can use that information to know what passwords not to try; and your users may find the bare minimum that passes your rules).

But to answer your question, the entropy of an 8-character password consisting of any number of digits, upper and lower case letters randomly chosen is lg(62⁸) ~ 47.6 bits (let's ignore symbols). The entropy of an 8-character password where exactly three letters are digits is 44.3 bits ~ lg (56 * 52⁵ 10³) (56 = 8 choose 3; the number of combinations of three digits chosen from 8 positions), so its slightly weaker. If you relax the condition to require it to be 8 characters and have three or more digits; then its still only 44.6 bits. So requiring d digits in an N symbol long password slightly weakens it compared to allowing any symbol, but only by a couple of bits of entropy. Though alternatively if you compare a 7 digit password without no number requirement lg(62⁷) ~ 41.7 bits and add a forced choice of digit inserted into space at random; the new password is 80 times (6.3 bits) stronger (ten choices for digit; 8 choices for location of forced digit).

Answer 5

The short answer is no.

Joseph Bonneau from the University of Cambridge has done extensive research in the area of user chosen passwords. His PhD thesis, which is based on an analysis of 70 million actual passwords, is a must read for anyone interested in the subject.

The following is from the concluding remarks of an IEEE paper he wrote (PDF):

As a rule of thumb for security engineers, passwords provide roughly equivalent security to 10-bit random strings against an optimal online attacker trying a few popular guesses for large list of accounts. In other words, an attacker who can manage 10 guesses per account, typically within the realm of rate-limiting mechanisms, will compromise around 1% of accounts, just as they would against random 10-bit strings. Against an optimal attacker performing unrestricted brute force and wanting to break half of all available accounts, passwords appear to be roughly equivalent to 20- bit random strings.

In other words an average user-chosen password has about 20 bits of entropy.

I'm not aware of any research done in the area of forced user selected three digits additions to passwords, but my guess is that the great majority of them would be one of four options: '123' prefix, '123' suffix, '111' prefix and '111' suffix'. If so, forcing users to add three digits to their password, while allowing attackers to know that user are doing do, would at best increase the average entropy from 20 bits to 22 bits.

Now adding 2 bits of entropy is a good thing as it multiplies the attack time by a factor of four. But forcing users to do so has a price both in poor user experience and (more significantly) false user complacency. If you're already going to the trouble of forcing the user to use a specific form of password, it's probably best to go all the way and force a password with high entropy or, even better, a computer generated password.

Answer 6

The short answer to this question is Yes

The longer short answer to this question is as follows:

A longer password say password and/or password123456789 is less secure then perhaps p1a2s3s4s5w6o7r8d90or something like P@ssW0rdT@Day24 futhermore its entirely possible to have a secure case-insensitive alphanumeric password that will be as secure as `P@ssW0rdT@Day24

NONE of the examples I used are actually secure because they are dictionary passwords.

Or is there some technical reason why a minimum of X digits, special chars, whatever is a good policy?

There is tons of research online on this subject I won't repeat that research.

Answer 7

The answer is No. Sorry Ramhound.

If I have to use at least x digits, it means that x characters of the password are guaranteed to be digits, of which there are only 10. You are reducing the search space by enforcing specific character types. As an attacker, I will gladly add your password rules to my cracking tool.

The reasoning behind these requirements is to force users to not pick "password" as their password. There are better ways to do this, but that's a different discussion.