I had a user today highlight an edge-case annoyance with the password generator, specifically for engineer-types, which prompted me to write this. I had initially considered a feature request, but after some thought I think it’s best suited for discussion only right now.
Currently the password generator policy only allows for setting ‘minimum’ requirements for special characters and numbers, which is good for security, however sometimes the password generator may be used for edge-cases scenarios like generating strings which make part of a connection query, or similar, which cannot include special characters for example.
The thought was to add additional policy settings for a “default” number of special character and numbers, allowing the minimums to be 0 and making the generator usable for this scenario. However, I do see how this opens the door for users generating weaker passwords, and reducing security. Definitely a double-edge sword. I do think a “set defaults” checkbox which introduces 2 additional inputs, has some merit though. You could set the minimums at say 2 respectively, but make the defaults 4. So users are encouraged to leave it at the defaults for more security, but could reduce it to a minimum.
I suppose really, a potential short-coming of the password generator is the org-wide policy, and having no granular user/group based control for different acceptance levels of minimum password complexity.
For the specific scenario of generating password-like strings, perhaps a new kind of tool which can be assigned to ‘Developers’ or ‘engineers’ based on group or individual users within an organisation, for generating long strings without special characters would make more sense?
I’m not sure I understand exactly what you are suggesting. Are you saying that you wish for some user groups to be able to override the organization policy for minimum special characters?
If so, why not simply set the policy to not require any special characters, but change the policy for minimum password length to increase the minimum length by 1 character? This will ensure that passwords strength is not compromised by the omission of special characters (and users still have the option to include them). See examples below:
Min. A-Z
Min. a-z
Min. 0-9
Min. !@#$%^&*
Min. Password Length
Password Entropy (bits)†
1
1
1
1
12
71.9–74.3
1
1
1
0
13
75.4–77.9
1
1
3
1
12
70.9–72.9
1
1
3
0
13
75.1–77.7
†Entropy calculations are estimates that attempt to account for the effects of constraining the required quantity of numerical characters (as well as the inclusion or exclusion of special characters); entropy reduction caused by constraints on the minimum number of alphabetic or or special characters has not been accounted for.
Thanks, grb, that makes sense and the examples help a lot. I see how increasing the password length can balance things out if special characters aren’t used.
I think the original point is more about flexibility for edge cases, like when devs need to generate strings that can’t have special characters at all. Maybe having a separate generator option or tool just for those use cases could be useful, without changing the main policy for everyone.
Would be interesting to know if anyone’s found an easy way to handle that in their org.
That is where the checkboxes at the bottom come into play. For the reason you state, requiring specials/numbers, etc. should not be enforced by policy. Better (IMHO) is for policy to enforce a minimum length. Or better yet, minimum entropy (not an available option today).
I’m not convinced that you understood my point. If anybody in the organization needs to generate passwords without special characters, simply refrain from setting a policy for the minimum number of special characters.
What I said above is the easiest way to handle it.
grb highlights some good points about options available, and thanks for those examples and stats.
The thing with the enterprise policy is when it’s set, it applies to all, and there’s no way to override it on a granular level. We want to ensure we are forcing our users to use the most secure passwords we can within reason, and include best-practices with numbers and special characters. But there are times where it would be handy to generate a password without these, which presently is not possible from within the enterprise-controlled spaces. Whilst the policy is applied.
If we reduce password complexity, or remove the need to include numbers or special character, users will most likely opt not to include them. Technically, as your entropy stats highlight, it doesn’t inherently reduce security… but it’s not ideal, an our company policy stipulates the inclusion of numbers and special characters in passwords (unless not possible, due to technical limitations or in the case where it’s not necessarily a ‘password’ but more a key/string, placed in BW for simplicity and accessibility) to meet certain security standards and certifications, so we cannot disable them completely.
Not sure why you say “it’s not ideal”, but your best bet would be to attempt to educate company management about why stipulating the mandatory use of special characters can actually weaken password strength (by reducing the pool of acceptable passwords that can be generated), and why increasing minimum password length can more than compensate for reduced diversity in character classes.
Here’s a simple example. Suppose that your generator only offers two character classes, consisting of 3 characters each: {a,b,c} and {1,2,3}. If both character classes are permitted, and no constraints are imposed on the minimum number of characters from either class, then a randomly generated password consisting of n characters could take on 6n possible values (corresponding to an entropy of 2.6 bits/character).
For simplicity, let’s assume the password has 2 characters (n=2); thus there are 36 possibilities:
a (2nd)
b (2nd)
c (2nd)
1 (2nd)
2 (2nd)
3 (2nd)
a (1st)
aa
ab
ac
a1
a2
a3
b (1st)
ba
bb
bc
b1
b2
b3
c (1st)
ca
cb
cc
c1
c2
c3
1 (1st)
1a
1b
1c
11
12
13
2 (1st)
2a
2b
2c
21
22
23
3 (1st)
3a
3b
3c
31
32
33
Now, look what happens if we impose a password “complexity” policy, requiring the generated password to contain at least one character from each character class. This disqualifies all passwords that do not have both a letter and a number, reducing the number of possibilities from 36 to 18:
a (2nd)
b (2nd)
c (2nd)
1 (2nd)
2 (2nd)
3 (2nd)
a (1st)
aa
ab
ac
a1
a2
a3
b (1st)
ba
bb
bc
b1
b2
b3
c (1st)
ca
cb
cc
c1
c2
c3
1 (1st)
1a
1b
1c
11
12
13
2 (1st)
2a
2b
2c
21
22
23
3 (1st)
3a
3b
3c
31
32
33
As I already explained previously, a better strategy for ensuring that passwords are strong is to impose a stricter policy for minimum password length. For example, if we increase the password length in the above example from n=2 to n=3, then even if the generator only used characters from one of the two character classes (e.g., no numbers), then total number of possible passwords would be 3×3×3 = 27, which is 50% better than the number of possibilities produced with the “complexity” requirement in place.
The above was a simplified example, but the same conclusions hold in more realistic scenarios.
In addition to what @grb mentions, another data point that may resonate with the decision makers is that NIST claims this is a bad idea. Would they would be open to updating the policy to state “X-complexity or Y-length”?
Even if you can’t budge the status quo, enforcing in the generator does not preclude use of a web-based generator or “I’ll make something up”. Perhaps suggest that the more effective enforcement point would be within the password change function on the web site(s).
This may also be a good solution for the developers/engineers at @dbtg’s company who need to generate random alphanumeric strings. Here is a good utility for this purpose:
If your corporate policy does not allow access to external websites, then you can simply download the (open-source) HTML of the above webpage and install it locally (on individual computers, or on a company-approved server).
Thank you both, great info and points very well made. You’re both obviously far more knowledgeable on the topics at hand, than I.
I shall look into whether there’s room for change in standards, and why we’re subject to certain criteria. I’m pretty sure it’ll be down to inaccurate information from a third-party enforcement body which we rely on to advise, or similar. Which sets the tone for our internal policies and guidelines.
We do utilize other forms of string and password generators online, specifically for the technologies in question. I think the query came about because of laziness and wanting to generate in the same place it’ll be saved. Copy and paste is such a difficult task these days, apparently haha.
