What Are Common Password Checks? 15
robra asks: "For a Web site I am writing using Java servlet technology I need to
ensure that users do not pick "bad" passwords. I know there
are many C programs like Crack which try to break encrypted passwords
and I could use one of those to see to it that users don't pick
a password that can be broken. However, platform independence is
a big issue and so I would like to stick to Java code only.
Does anyone know where I can find some Java code to check for
bad passwords?" In the interest of making this a little more open, what kind of tests do most password checking algorithms perform to insure a password isn't too easy to crack?
Some basic checks (Score:3)
The easiest ones are
Cracklib equivalent (Score:3)
Cracklib can be found on the Author's home page at http://www.users.dircon.co.uk/~crypto/ [dircon.co.uk]
Some other Criteria (Score:1)
Some other criteria I've seen people use as requirements for passwords:
Adding in those two requirements greatly enlarges the potential pool of passwords. Even if you assume only numbers will be used in addition to letters and not all the punctuation marks, you're still increasing your password base by several orders of magnitude. Requiring non-letter characters also means that simple dictionary attacks are bound to fail. Furthermore, those are all very simple requirements that are easy to check- unlike matching against the whole dictionary.
read the Crack docs (Score:2)
--sam
Longer passwords (Score:1)
Re:Purpose in password checking? (Score:2)
If it is some private information than you better have some good password validation. However if it is just to store some color preferences on a simple page, then no real validation is necessary (why even have passwords!).
Only you can answer this question. Once you have determined the necessity of password protection can you start to implement a protection scheme. And if you are protecting personal information, remember to encrypt (at least) the password in your database!!
things to check (Score:2)
- is not (or does not contain, for extra security) a word that's in your spellchecker's dictionary
- is not on a list of common names (the most common passwords are the most common female names)
- contains at least one non-alpha (for extra security: contains at least one numeric, one alpha, and one non-alphanumeric)
- minimum length of 8 chars
- does not match pattern of phone no., SSN, birthday, etc.
other options:========
Purpose in password checking? (Score:3)
When I sign up for a user account at a particular site, I like to use a simple password at first (a variation on something obvious, like 'pa55w0rd') until I'm sure that I like the site and will continue visiting. If there is some information there that I consider worthwhile, I'll visit more often, and take the time to come up with a decent password. But often, strong passwords are unnecessary -- people who are forced to choose difficult passwords against their will tend to forget them, and often won't come back, whereas people who choose good passwords and are concerned with the integrity of their (insert site here) account will tend to be more conscientious.
Here are some suggestions:
The problem with password validation is that it tends to not be fast, and running it over the web on a busy site, where there may be dozens or even hundreds of simultaneous instances of this password validator running, can get extremely messy. Keep it simple, whatever you do.
Here's a thought -- have the user enter a "password suggestion," rather than an actual password. Then run it through some sort of standard filter(s) -- for example, rot13 it, then turn it into piglatin, and then transform it into k3wlt0k. (Perl's Text::Bastardize module will do all of these, and more). That way, their preferred password is (sort of) preserved, while you are ensured that they have a (somewhat) obfuscated password. Coupled with minimum password lengths (like 8 or 10 characters) means a password that, at the very least, is pretty silly, and not something like "MyDogFred".
True example: I have a friend who insists on using the name of the site the password is for as the password, so that he will not forget it. Dumb dumb dumb.
darren
Cthulhu for President! [cthulhu.org]
Re:things to check (Score:2)
I have to disagree with this one. Most systems only hash the first eight characters, so the potential hacker only has to guess the first eight characters not the entire sentence. This is little better than allowing them to use a dictionary word as their pass. Of course, since this guy is writing the entire system from scratch he has the option of storing the entire password not just the first eight characters so my argument may not apply, but in general it holds.
Re:Some other Criteria (Score:2)
I would have to disagree.
Forcing the use of both upper and lower case letters actually restricts the possible combinations by at least half! (Disclaimer: this is all based on an OAC finite math course i took a few years back) Let's assume 4 character passwords, because the math is simpler: Total number of possible passwords (26 LC, 26 UC, 10 #) = 62^4 = 14776336 total passwords. because of the need to have at least ONE non-letter, the following is now true = 62*62*62*10 = 2383280 We just ELIMINATED 12 MILLION possible passwords! Now, since one letter MUST be opposite case (and not a number) we are at: = 62*62*26*10 = 999440 Well, there goes another 1.3 MILLION passwords! Out of 14 MILLION passwords, there are now only 1 MILLION acceptable passwords based on the critera. Now, on longer passwords, the effect of these constraints should be proportionally less.
Re:Bad math (Score:1)
Using all lower case is bad, but restricting the sample space to 4.5 million still makes it easier for a brute-force passcrack than leaving it alone.
The real question is: How far out of our way should we go to protect low-access user accounts?
The amount of information given to a would be cracker by having a default policy reduces the amount of time he has to spend by 1/3! If anything, that would make the server more inviting.
Again, it's all just a matter of how you look at the problem.
cheers
Re:things to check (Score:2)
========
Re:Some other Criteria...oops forgot to preview (Score:2)
I would have to disagree.
Forcing the use of both upper and lower case letters actually restricts the possible combinations by at least half!
(Disclaimer: this is all based on an OAC finite math course i took a few years back)
Let's assume 4 character passwords, because the math is simpler:
Total number of possible passwords (26 LC, 26 UC, 10 #) = 62^4 = 14776336 total passwords.
because of the need to have at least ONE non-letter, the following is now true
= 62*62*62*10 = 2383280
We just ELIMINATED 12 MILLION possible passwords!
Now, since one letter MUST be opposite case (and not a number) we are at:
= 62*62*26*10 = 999440
Well, there goes another 1.3 MILLION passwords!
Out of 14 MILLION passwords, there are now only 1 MILLION acceptable passwords based on the critera.
Now, on longer passwords, the effect of these constraints should be proportionally less.
Re:things to check (Score:2)
Bad math (Score:1)
U = {all passwords}
A = {passwords with no uppercase}
B = {passwords with no lowercase}
C = {passwords with no numbers}
(If none of this makes sense, review your combinatorics.)
Let a = not A, b = not B, c = not C
N(abc) = N(U) - N(A) - N(B) - N(C) + N(AB) + N(BC) + N(AC) - N(ABC)
N(U) = 62^4
N(A) = N(B) = 36^4
N(C) = 52^4
N(AB) = 10^4
N(AC) = N(BC) = 26^4
N(ABC) = 0
So the total number of possible passwords is 4572464, so about 4.5 million. So definitely more than your estimate of 1 million, yet significantly lower than the total number of passwords which is about 15 million.
The bigger point being made, however, is that since most people will use a password of all lower case which has 456976 possibilities, making these restrictions raises the sample space to 4572464 possibilities.