Slashdot Mirror


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?

3 of 15 comments (clear)

  1. Some basic checks by djweis · · Score: 3

    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
  2. Cracklib equivalent by Nonesuch · · Score: 3
    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/

  3. Purpose in password checking? by dlc · · 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:

    • 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!
    --
    (darren)