What Are Common Password Checks?

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?

Comments

Some basic checks

[djweis]

The easiest ones are

• username != password
• password doesn't contain username (eliminates pw of username1)
• not contained in dictionary
• length of at least 6 or 8 or whatever you're comfortable with

Cracklib equivalent

[Nonesuch]

Given that the user is providing you with the cleartext of their new password choice, you don't actually need to 'crack' the password, just check if it could be broken by the rules used by password cracking software. This is much easier.

Cracklib can be found on the Author's home page at http://www.users.dircon.co.uk/~crypto/

Some other Criteria

[rgmoore]

Some other criteria I've seen people use as requirements for passwords:

• Must contain upper and lower case letters.
• Must contain non-letter characters.

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.

Re:Some other Criteria

[Keeper ofthe Keys]

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.

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.

read the Crack docs

[petrov]

They have a config file which specifies all manner of password combos (letters/numbers appended, syllables flipped, words reversed); it should provide a comprehensive list of possibilities if you want to roll your own library. If you are doing a dictiionary check, make sure that you use a password cracking dictionary not a spell checking one. Password cracking dicts (as opposed to /usr/dict/words) have profanity and easy nonsense like asdfghjkl and 1234abcd. You can probably use the data files from Crack or John the Ripper in a Java system.

--sam

Longer passwords

[Emilio]

Just as a short addition, if you consider passwords of length 8, the restrictions allow for 159,655,911,367,680 different passwords which is about 73% of all possible passwords without the restrictions.

Re:Purpose in password checking?

[TeamFXML]

The above comment makes a valid point: What exactly are you protecting?

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

[turg]

check that the password

• 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:

• assign randomly-generated passwords automatically
• have users choose pass-phrases of at least 25 chracters -- requiring them to use spaces and punctuation. Complete sentences can be easier to remember than "hcv97e#" and just as difficult to "guess" if they're long enough.

========

Re:things to check

[Biolo]

have users choose pass-phrases of at least 25 chracters -- requiring them to use spaces and punctuation. Complete sentences can be easier to remember than "hcv97e#" and just as difficult to "guess" if they're long enough.

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:things to check

[turg]

Biolo wrote:

Most systems only hash the first eight characters, so the potential hacker only has to guess the first eight characters not the entire sentence

Um, but here we're giving advice to the person developing the software which hashes the password. So I'm saying that instead of hashing the first eight characters, hash the whole thing and require it to be at least 25 characters long.

========

Re:things to check

[Biolo]

Yeah, but the point I was making is that in most cases only the first eight characters matter. Last thing you want is people to start giving out advice about just typing a sentence in as their password! Take it from a sysadmin who knows! Anyway, I made your point at the end of my original post.

Purpose in password checking?

[dlc]

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:

• assign passwords. Choose a 10-character password with random alphanumerics and assign the password to that user (as Slashdot does when you create the account), and don't let them change it.
• Ensure that the length of the password is greater than 8 characters.
• ensure that no two characters next to each other are the same (to avoid passwords like '666' or 'fffffffff')
• good mix of uppercase, lowercase, and numbers, with at least one punctuation character.

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!

Re:Bad math

[Keeper ofthe Keys]

As I said, it's been a while since I took finite ... it's starting to come back, though.

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:Some other Criteria...oops forgot to preview

[Keeper ofthe Keys]

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.

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.

Bad math

[Emilio]

Let's use Inclusion-Exclusion (again with passwords of length 4)

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.