Our company works in health care, and we've written a corporate security policy, including passwords. Something that I noticed about the policy and have commented on, it says the password should not contain dictionary words. The spirit of this is right, but take my password for example, it's greater than 30 characters and is a passphrase, it does contain dictionary words, but at its level of complexity that's irrelevant. Also that doesn't eliminate passwords like p4$$w0rd0! which are equally as bad.

how can we write a policy that encourages people not to use bad passwords but does't accidentally exclude good ones?

  • 1
    One thing you also have to consider is the audience of this policy. For example, since this is the healthcare field, the users typically aren't going to care about entropy and time it could take to crack the password, and may be of the mindset that, if someone does gain access to their account, it's not a result of a poor password, but the result of poor corporate security as a whole.
    – user64273
    Commented Oct 19, 2015 at 16:12
  • @Zymus yeah the users don't care, but policies tend to be put in place because they don't care. Users wouldn't encrypt their drives and have passwords on their laptops if we didn't tell them. In fact I recall hearing a complaint about having to encrypt. Policies are not written for the people who will just do the right thing, but the people who won't. Sadly policies can be used to fire people who are doing the correct thing, but are not following the policy, because the policy is not right, because the writer didn't understand nuance, or didn't think of an exception, etc. Commented Oct 19, 2015 at 16:20
  • Agreed. I guess the point that I was making is don't make the policy so hard and strict that the users will ignore it anyways. For example, if you enforce no dictionary words allowed, then you'll need to get yourself a dictionary and prohibit the n most popular words; which won't really do much as the user will then likely use the name of a person or place. What I might enforce more is the length of the password (which increases complexity), rather than complexity itself (alphanumeric + symbols + non-repeating words + non-repeating numbers, etc)
    – user64273
    Commented Oct 19, 2015 at 16:28
  • My 2c: Take one of the good advices below AND strongly encourage the use of a suitable password manager.
    – Marcel
    Commented May 17, 2019 at 12:45

4 Answers 4


IMO, the criteria in a policy should be explicit, minimal and enforceable. "Do not use dictionary words," belongs in a best-practices document or the corporate security awareness training, not in the policy.

The policy should specify things like minimum length, complexity criteria, maximum (and minimum) age for each category of password. It is common practice to require longer passwords for accounts with elevated privileges.

Based on current GPU hash cracking performance, 10 characters chosen from 96 (upper, lower, digits, special including space) is the minimum length that should be considered and 12 would be a much safer choice. There has been a lot of discussion in recent years about the actual value of frequent password changes. One of the downsides to consider is induced bad behaviors. If users can't remmeber their password because it is changed every month, they will write it down or use guessable passwords and undermine the control.

I very strongly urge the adoption of two-factor authentication, risk-based authentication and Privileged Access Management solutions.

  • You can't make a generalization about "current GPU hash cracking performance". It varies by factors of thousands or millions based on which hashing algorithm you're using. Commented Oct 19, 2015 at 20:24
  • You are quite correct about the range of work factor and many hashing approaches have ways to adjust it as well. However, I was addressing the typical corporate policy scenario, which pragmatically means Windows AD. Commented Oct 20, 2015 at 17:25
  • I don't think you can make that assumption. 15 years ago that was a good assumption for a logins. Today many, many companies use websites for authentication that may or may not use Windows AD. Especially in Healthcare. Commented Oct 20, 2015 at 18:26
  • You are absolutely right about authentication with non-domain members. It is much more common now for those to be handled separate from the corporate directory. In my defense, 12 characters is a conservative recommendation. If you are using a newer hash that has a high work factor, you might be able to get away with fewer than 12, but 12 works across the board. Writing policies involves trade-offs. You need to avoid being so open ended that staff are left with judgement calls for each use case, yet also recognize the range of use cases. I stand by my answer as a policy recomendation. Commented Oct 20, 2015 at 18:46

how can we write a policy that encourages people not to use bad passwords but does't accidentally exclude good ones?

You need to understand two different things:

  • what a good password is
  • how users think about and deal with passwords

Your best bet, quite honestly, is to get someone in who has done this a couple times. A consultant or security architect. I'm not saying that because you could hire me, but because I've spent quite a bit of time at quite a few companies refining and improving the template I use and know which parts to adapt and which parts are non-negotiable due to security impacts. You're not likely to get that experience with one case and a single policy.

That said, if you want to roll your own, you first need to shed old and wrong conceptions. All these password complexity calculators are nonsense. I've so far always found something ridiculous that will pass them, and most of them are based on the wrong assumption that the attacker will use brute force as his method.

To get user acceptance, you need to find a scheme that doesn't put a burden on users. Frankly speaking, that's almost impossible, as both highly complex and very long passwords are a chore to type, especially if you need to do it multiple times a day. Using alternative authentication would be better, but here we are.

So once you see that "p4$$w0rd" isn't actually more secure than "password", you want to encourage your users to use non-trivial passwords and here's the catch: The more rules you write about what a good password is, the more you actually reduce the space of possible passwords. If I as an attacker know your password policy, I don't have to test any passwords that don't follow it.

Some specific guidelines:

Words are good, if you have enough of them, because people can type them fast and easy, which reduces the dangers of shoulder surfing. They are also easy to remember, which reduces the danger of them being written down.

Names are better, because they are less likely to be in a non-extensive dictionary, especially when it isn't person names but place names, pet names, historical names, foreign names and all that. And they are also typically easy to remember.

Numbers are ok, because they add a bit of variation, are easy to remember and type and can be used in passphrases ("we ordered 4 pizzas").

Special characters are complete and utter bullshit. They are harder to type, if you require them people will typically pick from the 10 or so that they can easily reach, which means your complexity is much less than if you used numbers, they are difficult to remember and are the easiest to shoulder-surf. And the few easy ones, like .,-!? in their logical places in sentences in a passphrase add about one or two bits of entropy.

What you need to do is run your own password checking. I quite often recommend to give people freedom to choose their own passwords, recommend passphrases, and run every new password picked against a blacklist of the top 1000 or so passwords plus a hundred or so company- and country-specific ones and their permutations. If the password is on the blacklist, it is too weak and the user needs to pick a new one, but at least they know why.

Then run a common cracking tool against the hash database at night and every password it discovers is set to "force password change on next login" with a message explaining why.

One more thing: You do want to be careful with the regular password change rules. The truth is that if you have a 30-day expiration date on passwords, 90% of people will have "password1" the next month and "password2" the month after. If you disallow consecutive numbers, they will use 1, 3, 5, ... instead. Humans are lazy and their password is one of the less important things about their job. You are probably the only person in the company thinking hard about passwords.

Make it easy for the normal user, and they will follow your guidelines. Make it tough and they will look for ways around them.


Something that I noticed about the policy and have commented on, it says the password should not contain dictionary words.

The requirement as you have stated it applied to pass words.

The spirit of this is right, but take my password for example, it's greater than 30 characters and is a passphrase, it does contain dictionary words

This section of your question relates to a pass phrase not a password.

There is no necessary logical inconsistency or difficulty here as long as the word "password" really means a single word and the phrase "pass phrase" really means a multi-word phrase. I think this is the way most users would understand these terms and so this starting point is justifiable.

A single word password should not contain dictionary words. A multi-word pass phrase can contains dictionary words. This is, as usual, justified by the complexity. For example, a single dictionary words has (base2) "entropy" of, say, 15 (assuming there are 30000 dictionary words). Whereas a four word pass phrase made up of dictionary words has an analogous entropy of 59.

To put it another way: "correct horse battery staple" is not a dictionary word (even though it is made up of and contains dictionary words).


There are a few options listed already that highlight the solution from a managerial standpoint. I find a mix of management controls and technical controls are effective. Relying on just one is doomed to fail.

From a technical approach, you can control some of the requirements via Windows' group policy. From Group Policy, you can control:

  • Number of Previous Passwords Remembered
  • Minimum Password Age
  • Maximum Password Age
  • Minimum Password length
  • Whether Password must meet a complexity requirement

With the complexity requirement enabled, the following 3 out of 4 are required:

  • English uppercase characters (A through Z).
  • English lowercase characters (a through z).
  • Base-10 digits (0 through 9).
  • Non-alphanumeric (for example, !, $, #, %). extended ASCII, symbolic, or linguistic characters.

Setting Microsoft Password Complexity

A question about Dictionary passwords was also raised over at SuperUser. It appears that there is a solution to control that as well.

  • though not part of my question... there is 0 windows involved at our company. Commented Oct 19, 2015 at 20:30
  • @xenoterracide Is it mainframe, linux, or what? Most OSes these days have password requirements built into the OS. My statement still stands: The best way to enforce policies is to include software restrictions.
    – pr-
    Commented Oct 20, 2015 at 12:43
  • 1
    @pr- I'm a few years late to the party, but this would belong in a standards document, not a policy. The policy defines what must be true about passwords. Standards define what specific technical controls must be put in place. Procedures and work step instructions define how things should be performed at different levels of detail and specificity. Commented May 17, 2019 at 16:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .