views:

350

answers:

5

Thanks for looking. All sincerely helpful answers are voted up.

I use a password strength meter to let the user know how strong the password they've chosen is. But this password checker obviously doesn't cover how weak under a dictionary attack the password is. How can I check for that, and is it worth it?

Also my regular password checker runs initially with javascript in the browser (no transmission required). If I want to check for dictionary attack weakness, I'd have to transmit it to a script. My understanding is that I shouldn't transmit it in the clear.

Can someone help me sort this out. How do I check the password isn't weak under a dictionary attack and how do I encrypt it before transmitting to my script?

Extra info:

Why do I think I need the dictionary attack check in addition to the regular password meter? As some of you have pointed out, users can choose passwords like P@ssword or Yellow12. But most password strength checkers I've come across will treat this as a good password. At least I'm using Yet Another Password Meter and it does (and I actually think it's one of the better password checkers.) If anyone knows of a stronger password checker, please mention it, but only if you know for sure based on experience that it's stronger ;)

But my question really is: how do I conduct a dictionary attack check on the password? I read somewhere that it's done against the hash, but where do I do the search? Once I find out how to do it, I will then decide whether it's worth it or not.

thanks to everyone who's helped out so far :)

+6  A: 

Opinions are going to vary and some people will say that checking for dictionary words is important. I disagree and instead favor requiring different cases of letters, numbers and special characters like !@#$%^&()-=+. Obviously passwords should be case sensitive.

Dictionary attacks are much less likely to succeed with the presence of numbers and special characters. Lets say that there are 1000 common passwords. Now with the addition of a required upper case letter and special character lets assume the user is "lazy" and they choose to make the first letter capital and add a special character to the end. That 1000 sized dictionary is now over 30,000.

Additionally there should be account lockouts in place to avoid dictionary attacks. And possibly a throttle on how often an IP address can attempt to login depending on your application.

There may still be a case to avoid some very common passwords while running your script. I would for example not allow the word password p@ssword or any variation of password.

Edit: A captcha, while hated by most (including me) may be appropriate as well after a few failed logins to avoid brute force login attempts.

No longer a user
Yeah, but that p@ssword example violates typical mixing of casing, requirement of numbers and symbols, and if you disallow repeating chars consecutively, that is typically good enough for passwords. If it's not then you probably need biometrics or 2-factor authentication. :)
BobbyShaftoe
Correct, I should have said P@ssword in my example. I guess what i was getting at is do something along the lines of change @ to a and 0 to O and do not allow password at all ignoring the character case.I agree, requiring mixed cased letters, numbers and special characters is sufficient. I probably shouldn't have mentioned it :)
No longer a user
You bring up the p@ssword example. That's exactly why I'm thinking I need the dictionary attack protection. Most password strength checkers (even the good ones) would rate something like P@ssword or Yellow12 as good.
Chris
A short list of unacceptable passwords in a JavaScript file would not really hurt anything. Something like this list http://www.pcmag.com/article2/0,2817,2113976,00.asp perhaps while again normalizing @ to a and 0 to o, etc. I wouldn't waste any time trying to literally have the entire English dictionary checked though.
No longer a user
+3  A: 

If you are using proper complexity requirements (length, mix of casing, numbers, symbols, and perhaps forbid repeat a char consecutively) then I'd say it's not really worth it. If you're in a situation where that would be required then probably password authentication would not be good enough for your situation anyway.

BobbyShaftoe
+3  A: 

SSL

If your website in any way or on any page requests sensitive personal information, including passwords, then you should enable and enforce SSL across the entire site. This will ensure that all passwords are transmitted in encrypted form from the browser to the server, and that nobody can sniff the passwords off the network or modify the pages in transit (and alter the form postback url's).

Password Meter

You should run your password meter entirely in the browser. You should accept any and all passwords (with a min length of, for example, 6 characters) that the user enters, but feel free to hint to the user, from within the browser, whether they have entered a weak or strong password.

Justice
I would also clarify that the complexity check should be done server side, because javascript and other browser scripting languages can be bypassed. So you definitely need the SSL to send it over to the server. The password meter is just a nice to have.
Hans Doggen
My point was that you should not do a complexity check. Rather, you should permit weak passwords. You should simply notify the user, using JavaScript, that the password is weak (but that the user may use it anyway). The only server-side check should be a min-length/max-length check (and both min and max lengths should be generous: 4 and 40, perhaps).
Justice
But you might have requirements to only allow complex passwords. If this is part of your business logic then of course you should check on the server side. However, I agree, if you are at this stage, you should be using SSL.
BobbyShaftoe
Correct. If there is a business reason to require certain types of complexity in passwords, then you will have to implement it server-side (and perhaps, also, client-side). But typically, these business reasons are stupid and their ultimate effect is to reduce the security of your website.
Justice
+3  A: 

I'm coming to this question later than the others, and I'm surprised that no-one has pointed out that a dictionary check might not be exhaustive. At least no-one has said it in so many words.

I think you need a large dictionary, where each entry is hashed and compared to the hashed password. This will allow you to say the user's chosen password is not in your dictionary, but how will you be sure it's complete?

Obviously, you can't be sure. Do you include foreign words? Technical words?

Do password crackers have access to better dictionaries?

I think all you can do is advise users how to create a good password — show them a few examples — but let it be their choice.

And do the SSL thing.

pavium
Good point. Maybe it takes a lot of processing to get the dictionary attack check done. I'm reconsidering it now.
Chris
+3  A: 

One additional point - if you control the site, you can stop dictionary attacks by limiting the number of times a user can try a user/pass.

It is great you want your users to have better passwords and you should continue in that direction but a better solution for the dictionary/brute force attack would be an exponential backoff solution to failed login attempts. No real user will try and login 1000 times in 10 seconds with all different passwords.

Collin
Exactly my thoughts
snomag
+1 How did I miss this one.
Chris