I need to implement a 'stop list' to prevent users selecting common passwords in a new online service.

Can anyone point me to such a list online anywhere?

Edited: Note that I'm only trying to eliminate the most common passwords, not an exhaustive dictionary. And, of course, this complements a reasonably strong password policy (length, use of non-alpha characters, etc.)

11 Answers
11

If it is a customer requirement to check against a list of known bad passwords then I would probably ask them to supply the list of passwords they think are bad. If they can't supply the list then I would go with the password complexity rules as suggested by others.

I'd +10 this if I could. If the customer has come up with the requirement, then make them take the requirement to it's logical conclusion, otherwise you're almost certainly not providing what they expected (either not providing the coverage they were expecting, or wasting their money on excessive password list hunts).
–
wombleNov 19 '09 at 21:14

A good plan. And I did ask. I'm struggling to find a politically correct way of describing the nature of this customer and why they don't work that way. It's too hard, so I won't bother. So, in the spirit of peace and harmony, I'll gather the list and give it to the customer to approve. I've found a list of the most common passwords from 2005. That'll do, I reckon!
–
Steve MorganNov 19 '09 at 21:19

1

Stuff political correctness: "the customer is an idiot". Happy to help.
–
wombleNov 20 '09 at 18:34

2

I disagree, I dont think this is a semantics or customer is stupid issue...indeed I think its amazing the customer is even cognizant of this issue. Comparing against a list of terrible passwords like 'pa$$word1' that pass traditional regex validations seems like a good precaution to me.
–
juwileyMay 22 '12 at 19:28

The annoying thing is that I can understand and even empathise with where they're coming from. But this requirement will only cause grief and hassle in the long term (I can see, for example, a future requirement for the list of "known common passwords" to be updated on an annual - or even more frequent - basis). Password complexity requirements are known to work in the field, and even the most basic complexity requirement (such as any 3 of uppercase, lowercase, numeric or symbol) will automatically exclude the vast majority of dictionary words.

Another deal breaker is that a lot of people will use things that they are familiar with as a password. A social security number, for example, might meet a complexity requirement (numbers, letters, and a hyphen, perhaps), and would certainly never be in any hypothetical list of "known common passwords", but would also be un-secure in that it's one of the things a potential cracker would try (assuming that they either knew it or had the means to obtain it).

One online service I used once gauged password security by measuring a combination of factors: how many of each type of character was in the password, and how long the overall password was. Instant feedback was given, so you could get a good feel on whether your password was deemed good or not based on their metrics. Such an approach seems much preferable to me.

Also attractive would be using a service such as OpenID or Microsoft Passport (or whatever it's called this week) instead of implementing your own. I'm massively suspicious of services that require a user to have a separate logon for everything they access. The major risk is that the user has so many username/password combos to remember that they will end up writing them down, and also that they will end up using the same username and password for them all, so that if one - and all it takes is one - gets compromised, they're all effectively compromised. The weakest link rule applies here with knobs on. Going with a provider who specialises in this area is a Good Thing (you're free to focus on specifics of your service, you have an authentication mechanism that's known-good, etc).

The site you linked does indeed have a list of common passwords. Unfortunately, they're not delimited. I got bored splitting them into separate lines and Googled again. This time I came up with openwall.com/passwords/wordlists/password.lst which is a reasonable starting point, I think.
–
Steve MorganNov 19 '09 at 21:27

Have you tried opening them in an editor that understands Unix carriage returns. I believe Notepad++ should work. It can also convert the carriage returns between Unix and Dos if need be.
–
3dinfluenceApr 26 '10 at 17:39

Why not just enforce good password policies. Something like at least 8 characters, mixed cases, at least 1 number, and 1 non alpha-numeric character. Other than that there are a number of good dictionaries that you can compare passwords to.

We're doing that, too, but have a specific customer requirement to eliminate those derived from common passwords (like P@55w0rd). No problem normalising the characters, but want a list of common passwords to then check it against.
–
Steve MorganNov 19 '09 at 20:54

I would just run it through cracklib, sourceforge.net/projects/cracklib You could also map the user input to all lower case letters and alternate substitutes and run those through cracklib as well. Beyond that you could add security questions or a 2nd level of auth such as the images that banks use if the computer doesn't have a cookie for the site.
–
3dinfluenceNov 19 '09 at 21:18

@3dinfluence Thanks for the suggestions, but it's a bit of overkill. AD can natively handle all of the password policy requirements except this one for a stop list. It's easy enough to check against the list - I just need to source the list.
–
Steve MorganNov 19 '09 at 21:23

AD can do most of the password policy checking, but I have a specific customer requirement to check against a list of common passwords. It shouldn't be a big list and is complements the regular password policy.
–
Steve MorganNov 19 '09 at 20:58

A list of common/easy passwords is a big list. It's huge! Take a basic wordlist, square that number to represent a two-word phrase and you've still got a metric butt-load of easy passwords. Then do the old '1' suffix, and you've got even more, and they're still easy! This may be a customer requirement, but mathematics says a static list is a poor technique. It might be time to offer friendly advice, if at all possible.
–
pboinNov 20 '09 at 0:55

I agree that just having a strong password policy is probably a better idea.

If I really wanted to implement what you said, I think you will need to find a couple of good dictionaries. You will then want to generate all the hashes from variations on that dictionary, and then check their hash against that list. This is called a rainbow table, and in the attack world, is known as a time-memory trade off. If you don't do it this way, the check on the server will really just take too long.

Even better, might be to use a tool that generate a bunch of bad passwords from the information they filled out the form with. See CUPP as an example python program that does this.

Thanks Kyle. Note that I don't need to do a check against a comprehensive dictionary, but a list of common passwords, so I would expect the list to be reasonably short, once 'alpha-like' characters had been normalised.
–
Steve MorganNov 19 '09 at 20:56

Rather than trying to work with a list of bad passwords you would do better to use whatever method is available on your system to force password complexity, if possible. If you still want lists of bad passwords hunt around for the dictionary lists used by password crackers.

AD can do most of the password policy checking, but I have a specific customer requirement to check against a list of common passwords. It shouldn't be a big list and it complements the regular password policy.
–
Steve MorganNov 19 '09 at 20:58