What is worse for password strength, a poor password policy or no password policy at all?
The question is: worse for what?
With the policy you posted, the possible passwords are less than 64⁸ (~2.8*10¹⁴). In practice, very much passwords will probably be [a-z]*6[0-9][special char] (e.g. aabaab1!) and similar passwords.
All possible passwords with the same characters and length less than 8 are just 64⁷+64⁶+64⁵+... which is ~4.5*10¹². Thats a lot less than the passwords with length 8, so it doesn't increase security much to allow them. (allowing longer passwords would obviously increase security a lot)
Without any policy, many people will also use bad passwords, sure. But an attacker can't be sure about that. Also some people will use better passwords.
Without any policy, an attacker can never be sure how hard it is to crack a password. If you give me a DB of password hashes, I might try to crack it. But if there are no results, after some time I might stop. With the policy in place I can be sure that after 64^8 tries I have all passwords.
I would say, a bad password policy is worse. But it depends on the attack scenario.
With a dump of password hashes, with no password policy it is very likely easier to crack any password but harder to crack most passwords. With a bad policy like the one given, it is easier to crack all the passwords but slightly harder to crack the first one, most likely.
If your concern is how hard it is to crack your own password, without any policy you can use a secure 20 char random password if you want. With the policy in place, you are forced to use a insecure password. (in practice, it's more relevant how the passwords are stored and so on, but that's out of scope here). So as a user of the website/service, a bad password policy is a lot worse.
If you look at it from an organizational standpoint, a bad password policy is way worse than none.
No password policy means, probably nobody thought about it (not very good that they don't think about security, but ok...)
But a bad password policy means: Somebody thought about it and came up with that crap. This means they probably have no clue about security.
In the end, if you can implement a bad password policy, you can also implement a good one so there is no excuse for a bad password policy ever. Just changing the policy to "A password has to be at least 8 characters" would increase security a lot and isn't hard to do.
Now I'm wondering what is worse for password strength. Having no password policy at all or a poor password policy like in the picture?
The password strength requirements you mentioned absolutely do more harm than good, especially the maximum length.
- They might be using a very old, insecure hash routine. (thus a max-length)
- In certain areas, this supports convenience over security.
(no spaces is helpful when representing a password in plain text,
case insensitive so there are no caps-lock support calls) - Other items are just plain dumb.
Detailed Breakdown
Your password must:
- Be exactly eight characters long
The only time I can see this as a reasonable solution is when the system is running a legacy hash scheme which truncates all but the first 8 characters.
For example, Solaris 10 user account passwords used such a scheme by default, so passwords like passwordSup@rsecur☺ were truncated to password!!! The default for Solaris 11 does not have this shortcoming.
In this case
The developers should be working on migration to a better hash routine which supports password lengths beyond 8.
Until such a fix is rolled out, the maximum length is sane.
In any other situation, it would most certainly be a stupid thing to have such a short maximum length.
Include at least one letter and one number.
Include at least one special character from the following set: ...
These are a must given their short maximum length. I'm sure you can understand the need to use such primitive methods to increase entropy when a short password is used.
- Note: the password is not case-sensitive.
While this may be convenient for the user (don't worry about caps-lock), it is never recommended as it always decreases the entropy of the password. In this case it is even more highly discouraged due to the presence of a maximum length of 8 characters.
This should be fixed but now it would be trouble for them because existing users are already accustomed to the insecure configuration!
Not contain any spaces
The only reason I see for this is if they are presenting the password in plain text. (i.e. forgot password email, or tech support lookup) By most standards that is poor (not secure) software design.
A better policy is to forbid lookups and only allow it to be changed. In fact, it is highly recommended to use a Strong (Slow) Password Hash such as BCrypt which inherently forbids lookups as part of its core design.
- Not start with
?or!
Very strange, but not a significant killer of password entropy.
- Not begin with three identical characters
Meh, I'm not too concerned about this one, but I wonder why they only look at the beginning. 3 identical/adjacent characters anywhere in an 8 char password is weaker than it could be.
- The password must be different to your previous 5 passwords.
There's probably a dedicated Security Stack Exchange question for this subject. This is a common practice for online banking and certain other authentication systems.
I assume this is also coupled with mandatory scheduled change of password. The likely outcomes are:
- Users will write down their password instead of using their memory,
- Or, users will choose a simple pattern.
However, if password change is not mandatory, then the only problem is
- One must continue to store the hash value of the unused passwords for comparison to work.
and while that is not a serious issue, it is frowned upon.
A bad policy like this is worse than none.
This policy means that people who normally use '123', will now have a bit more secure password, but it's still weak. It also means that the people using something like 'fzFEZ#5$3rt4564ezezRTyht' (randomly generated), or just: 'cat j_umps over the brown painted wall412' (strong entropy), will now have a much weaker password.
The people using weak passwords anyway will get hacked in this case too (because this restrictive and weak policy, and the attacker being able to set specific attacking-rules). But people normally using strong passwords also will.
In other words, it's a lot less secure. Without any policy, only the people using weak passwords are vulnerable; now everyone is vulnerable.