What is worse for password strength, a poor password policy or no password policy at all?

Question

Recently I saw the following screenshot on Twitter, describing a obviously terrible password policy:

I wonder what is worse for the password strength. Having no password policy at all or a poor password policy (like described in the screenshot)?

Answer 1

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.

Answer 2

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.

1. They might be using a very old, insecure hash routine. (thus a max-length)
2. 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)
3. 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

1. The developers should be working on migration to a better hash routine which supports password lengths beyond 8.

2. 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.

Answer 3

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.

Answer 4

in my opinion having none would be better A list of reasons are:

• These policies make people tend to write down there passwords and stick them to the monitors or alike. (what security does a password than supply?)
• These rules are easily deduced and (by using these type of boxes) even announced to any potential intruder. (Like lets give the person we want to keep out the 'rules' of how our passwords are so they only have to do a limited set...)
• The entropy of a password significantly improves by making them longer. 8 is in these days trivial enough that an attack could use a mobile device to brute-force a password.
• the rule to mix cases and not check for them suggest that the password is stared in a plain text form (even if the storage is encrypted, most of the time the encryption key is stored with the data which effectively means there stored in clear text).
• For most applications a different schema would allow for far greater security without requiring a password at all, like:
  • 2 Factor authentication.
  • Secondary device authentication.
  • Smart card authentication.

These policies seem to be thought out by someone who does not fully understand how threats to a password impact your system. instead they just tick 'all the boxes' for some reason.

that being said there can be a real reason for why they did this. some certifications and uses require some of these to be implemented (think in the health sector or some government use).

Answer 5

None at all is better than the one shown, specifically because of the 8 char limit.

All 8 char combos can be tested in a second with a Titan-family GPU and John the Ripper. While not all password policies are detrimental (min length is good, one+ special char forces a bigger crack alphabet, no dictionary words, etc), the one shown is a joke that's not very funny. In sum, yes, that's worse than nothing because it won't allow password managers or smart users to protect themselves better than the default policy.

Policies should never stop good passwords, only terrible ones.

Answer 6

What is worse for password strength, a poor password policy or no password policy at all?

That depends on what the poor password policy is.

• "Your password must be 'letmein'" is a poor password policy that is definitely worse than having no policy at all, since it prevents anybody from having a good password.

• "Your password must be at least two characters" is a poor password policy that is definitely better than having no policy at all, since it allows anyone to use a good password and prevents some bad passwords.

Answer 7

There are a number of good answers already but I always like to look at this from a slightly different perspective. When you are considering how something will affect attempts at cracking a password you have to look at how they will be trying to do said cracking. Basically this boils down to two methods. Brute force and "intelligent" guessing so lets look at those two.

1) Brute force.

This is exactly what it sounds like. They try every possible password. This is the classic trying every pin from 0000 to 9999 on a 4 digit numeric lock. The key factors here are the Number of possible passwords and how long it takes to try each guess. Here the password rule might be great and completely eliminate brute force as a viable option due to the 8 digit requirement. It might also be completely catastrophic if a weak enough hash is used and might guarantee that every possible password is cracked in a reasonable amount of time to an attacker with enough resources.

Given the rules in this case seem to strongly suggest something fairly old on the back end it is entirely possible, if not likely, that the password is hashed with something fairly weak like MD5 or SHA1 and probably not salted and the rules might be catastrophic. Primarily the length but also not being case sensitive which reduces the possible characters by ~30%. They currently have 26 characters + 10 numbers + 28 symbols for 64 different characters in a password. They would have 90 characters if they were case sensitive.

Based on some quick searches it seems like if we assume an attacker with a reasonable amount of resources and that they are using one of those weak hashes it seems very likely that the rules are indeed catastrophic and if they aren't now they are certainly in danger of becoming catastrophic in the near future as computing power increases the cracking rate. A password longer than 8 characters may be required to be secure but they don't actually allow it.

Is it possible to brute force all 8 character passwords in an offline attack?

2) "Intelligent" guessing

At some point the brute force method gets impractical, it would take months to test all the passwords, or impossible, it would take millenniums to test them all, and "intelligent" guessing takes over. This is where you see dictionary attacks, either literal words from the dictionary or lists of previously used passwords, and rules based attacks. The rules based attacks take the dictionary and start adding on or changing things to make different variations of those passwords. Adding a number and one special character on to the end of a six letter word to get an 8 digit password that meets the password requirements. Making the password "leet" by turning password into p@ssw0rd which would be a valid but quickly cracked password in this system, etc. These rules can be almost anything you can dream up that you think makes sense and constantly evolves as we learn more about how people typically pick their passwords based on past leaks.

Assuming the cracking got to this point the password rules they gave would end up incorporated into the rules the attacker used to generate their possible password. Here their rules aren't as catastrophic but would still lead to far less valid possible passwords so would speed up cracking. It would also likely lead to some very predictable passwords with symbols/numbers added on to the beginning/end of the password or as part of a very predictable substitution.

Answer 8

I'm going to go a different route than all of the other answers so far... and say that at some point, it doesn't matter. The algorithm matter FAR more than the password rules.
For example, someone might use ROT13, terrible, yes.
Or, get a bit better an use MD5.
Or, better yet, SHA-1.
Maybe then they add salt.
Maybe use crypt().
Maybe then add pepper.
Still, a GPGUP can burn through billions of password hashes in a second. So, what else?
SHA-2-512 with 128 bit salt. Much better, still, GPGPU can do a lot of these.
Change to bcrypt. Much better. Now, we are getting past the point where a single GPGPU can just burn them all fast.
Change to PBKDF2, with full salt and pepper and 10,000 rounds.
Up that to scrypt, and now a very short password is 'uncrackable' since the algorithm is so slow.

Here's a table that might help explain it:

    Tries/sec
NTLM    350,000,000,000  
MD5     180,000,000,000  
SHA1     63,000,000,000  
SHA512Crypt     364,000  
Bcrypt           71,000    

So, a crappy password hashed with bcrypt is better than a great one hashed with MD5.

Answer 9

It really comes down to the end user. The way I see it, if you as a company/website are not liable if someone's account is compromised, it's best to forgo a formal password policy, at least a restrictive one.

I've always been of the opinion that the user should be responsible for their own security given that they understand the implications of things like weak passwords.

Granted, that last part is key, as if the user doesn't know any better you should force them to have a more secure password than what they want to use. But a password policy should only encourage more secure passwords, and not limit password strength, as your example illustrates.

I've run into this personally with my Universities website. My alphanumeric password of considerable length didn't satisfy there password policy, which discouraged some (but not all :/) special characters. The result was an intentionally weaker password, as for me it was more difficult to remember a password that I have not intentionally committed to memory.

And especially in that case, I suspect that the "password policy" was more of an excuse to avoid some string parsing/sanitation on the backend than it was a legitimate way to encourage better security.

Finally, password policies, if implemented, should change with time. That is, what might have been considered a secure password in the 1990s is no longer so in 2016, when the average consumer can leverage cloud computing or GPU clusters to throw an enormous and ever-growing amount of computer power at your passwords.

Answer 10

If users were picking passwords randomly then password policies would make security worse by limiting the choice of possible passwords but users don't pick passwords randomly. The aim of a good password policy should be to push a user to make more choices and hence choose a stronger password without unduly limiting the password space.

This policy has good and bad aspects.

be exactly 8 characters long

A minimum length is good, a maximum length is bad.

Include at least one letter and at least one number.

This is good, it pushes users towards choosing both a letter-based component and a number-based component.

Password is not case-sensitive.

This reduces the size of the password set significantly. On the other hand most people don't use capitals unless forced anyway and when they do use them they tend to do so in predictable ways.

Include at least one special character

Again good, it pushes the password creator into making another choice.

Forbidden spaces and rules on ? and !

I doubt these make much difference.

forbidden repeated characters at start

Probably a good thing, means the user can't just fill the password with repeats of a single letter.

Overall I would say if you have clueless users this policy is probably better than nothing but if your users have a clue about decent passwords it will probably do more harm than good.