# How come a controlledly generated password is more secure than a purely randomly generated one [duplicate]

In a software like keepassx, to generate passwords, there's usually the option to tick some boxes. For instance, a box that makes sure that at least 1 character from every lists of characters has been chosen. Where the lists of chars can be lower cases, upper cases, digits, special chars, etc.

I understand that a purely randomly generated password can produce passwords like "aaaaaaaaaaaaaaa" which aren't secure. But in average, I don't understand why making sure that there's at least 1 char from every lists is more secure than a purely randomly generated password.

How come it's possible to "beat" (in terms of security) a purely randomly generated password? Shouldn't these kind of passwords contain the most entropy in average, rather than a password made with human intervention?

Edit: If I have to assume I must protect against a cracker, I assume he uses all possible kinds of attacks. Brute force, dictionary, etc.

Edit 2: I've been thinking on it during the night. I noticed that if the password is very large (say length > 25) then the difference between ticking the box to make sure that there's at least 1 char from each group and not ticking the box is almost nil. Because the probability that there's no char from each group is very low. The other extreme case is when the password is very small, say of length 4. The case is more complex and I'm not sure which is more secure against all possible kinds of attacks.

• @techraf For one, because this removes the possibility of passwords like "aaaaaaaaaa" or "123456789". And also because if this lowered the security, I don't think they would propose it (unless it has a benefit like being more human readable and thus more easily being input by hand although this could severly hurt the security). Jul 17 '16 at 3:20
• @techraf I'm talking about keepassx (I don't know about keepass). But there's an option to pick at least 1 char from each groups (lower, upper, digits and special chars). This avoids the 123456789. Jul 17 '16 at 3:34
• I see. Regarding your statement "if this lowered the security, I don't think they would propose it": if there was any option which you can turn on or turn off and either setting would improve the security, then automatically the other setting would be lowering the security, right? Does your thinking still hold true when there is any option at all? Jul 17 '16 at 3:41
• @techraf I assume that when there is no option, the higher possible security will be picked. Or that the lowering in security is too tiny to be exploited (like the use of /dev/urandom compared to /dev/random). Jul 17 '16 at 3:45
• Ok, but there is an option which user can select/deselect. Either one fits your condition "if this lowered the security, I don't think they would propose it". Why then did you assume selecting particular state is more secure than the other (and not the other way around). You state: "why making sure that there's at least 1 char from every lists is more secure", why did you choose to write the word "more" here? Jul 17 '16 at 4:01

Many sites have complexity requirements. One advantage of the check boxes is to guarantee your password will actually be accepted by the website that you are generating it for. Another reason is psychological. People will believe the password is less susceptible to guessing if it has these character requirements. Realistically, a password with 80 bits of entropy that is completely random and a password with 80 bits of entropy that has these requirements are both strong enough that guessing or a brute force attack should never be an issue, even if for no other reason that the attacker will get enough passwords that running his brute force machine for another few years just to get the last 0.25% of the password hashes that he stole broken isn't worth it.

Edit: I'd like to emphasize that determining how much entropy a password has is not so much an exact science as it is an approximation. As discussed in one of the links in Jedi's answer, different password generators have different algorithms for this, so if KeePass says one password "beats" another in terms of calculated entropy, but the difference is only 1 or 2 bits out of 30+ total bits then there may not really be an advantage of choosing one over the other. Of course with very small passwords a single bit may be significant, but I hope everyone reading security.se keeps away from obviously horrible passwords.

An important reason for the "tick some boxes" approach is because too many sites have their own unique password policies (`your password must be a palindrome in iambic penatameter` etc.)

But in average, I don't understand why making sure that there's at least 1 char from every lists is more secure than a purely randomly generated password.

I wouldn't assert that it is more secure, just that brute force dictionaries containing one type of character (all lowercase/uppercase/numbers) were widely used back in the day. Similarly, hashes for many of these classes of passwords are already computed and stored in many rainbow tables.

How come it's possible to "beat" (in terms of security) a purely randomly generated password?

A bad password is simply one that is widely used / known / matches human behavior. e.g. humans tend to use dates, tend to have a sequence of digits; if an uppercase letter is required it is often the first one, if a special character is required it is often the last one etc. (I'll try to source this soon).

Considering a large number of users, it is non-trivially likely that passwords corresponding to known bad patterns are "randomly" generated some of the time.

Let us assume that all "random" passwords of length 'n' are equally likely to be generated. However, some percentage of these passwords are much more likely to be brute forced. This is what makes it worse.

Shouldn't these kind of passwords contain the most entropy in average, rather than a password made with human intervention?

I would like to link to a previous post discussing how the entropy of a password is computed (includes a link to a recent evaluation of passwords)