Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

Thanks.

share|improve this question

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.

share|improve this answer
1  
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). –  womble Nov 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 Morgan Nov 19 '09 at 21:19
1  
Stuff political correctness: "the customer is an idiot". Happy to help. –  womble Nov 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. –  juwiley May 22 '12 at 19:28

Doesn't the old Unix "crack" tool come with a list of common passwords? I believe it has brute-force and dictionary methods.

share|improve this answer

I think this customer needs to be beaten over the head a little. :)

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

share|improve this answer

Most people use Dictionary word lists for this type of thing. I can't vouch for how good these lists are ... but here are a few

If you just google "dictionary word lists" you should get a bunch of results.

share|improve this answer
    
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 Morgan Nov 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. –  3dinfluence Apr 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.

share|improve this answer
    
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 Morgan Nov 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. –  3dinfluence Nov 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 Morgan Nov 19 '09 at 21:23

Don't use a static list. Consider running John the Ripper to see if the pw is too simple.

John the Ripper

share|improve this answer
    
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 Morgan Nov 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. –  pboin Nov 20 '09 at 0:55
    
I agree. –  user39009 Aug 24 '10 at 11:38

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.

share|improve this answer
    
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 Morgan Nov 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.

share|improve this answer
    
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 Morgan Nov 19 '09 at 20:58

Sad story, but my best password list is one I got while examining a server of mine which got compromised.

share|improve this answer

L0phtcrack i believe came shipped w/ a list of passwords that it tried first, similarly, you could look at some analyses of Conficker.B which also had a list, albeit a short one, of passwords.

share|improve this answer

Ignoring the fact that is not a very good security solution (as stated by others on their answers), I'll answer what you asked (a list of common and bad passwords).

I find this list of '500 common passwords' quite insightful.

You can get the list of words with this script, except for a duplicated '0' password I can't help but parse out:

curl -s http://www.whatsmypass.com/the-top-500-worst-passwords-of-all-time | sed -n -e '/\(^<td>\(1\?[0-9]\?[0-9]\)<\/td>\|NO\|Top.*\)/d' -e 's/^<td>\(.*\)<\/td>/\1/p'
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.