14

Most password policies require the password to be at least 8 characters long and contain symbols from at least 3 classes (lower case letters, upper case letters, numbers, other).

Problem is, that a password "pa$$w0rd!" will be passed through by such policy while at the same time, it will be found/cracked by a tool like John The Ripper in seconds. (or in a case of "pa$$w0rd" by a rainbow table search)

How do I deny usage of such passwords? (I mainly ask for PAM mechanisms, but Windows solutions will be useful for other people too)

How to automatically detect passwords that are based on modification of dictionary words using leet speak, adding only 1 or 2 symbols or numbers, changing case and similar modifications.

Could checking for weak passwords using tools like John or rainbow tables be considered "best practice"? Should I definitely do this when I start managing a new network?

Improve this question
3
  • 2
    While this question is about password auditing, don't forget the user side of the equation. Forcing your end-user to have passwords they cannot remember or forcing them to change them too frequently will lead to user non-compliance. Make your password policy consistent with the information the passwords are protecting. Consider a tiered password policy where machines with more valuable information have more stringent password policies, and those with less valuable information have looser password policies.
    – this.josh
    Commented Aug 15, 2011 at 18:36
  • @this.josh: "Consider a tiered password policy" I'd gladly do that, if you only could point me to a Single-Sign-On solution that can do that... Updated the question to be more clear what I want to protect against. And I already allow passwords that use only 2 classes, provided they are 20 letters long, or are pass-phrases of 3 words and more than 14 characters. This makes my "have to have all 4 clasess for 9 character passwords" policy least secure.
    – Hubert Kario
    Commented Aug 16, 2011 at 9:37
  • 1
    I think you want to protect your passwords against a adversary obtaining your password database and performing an offline atack against that database with tools like John The Ripper. A tiered password policy could not be used with Single-Sign-On, because it necessarily divides the network into tiers. Single-Sign-On brings your level of protection to the level of the least protected system on the network. It is an inherent trade to gain useability at the expense of security.
    – this.josh
    Commented Aug 16, 2011 at 17:49

2 Answers 2

Reset to default
13

Could checking for weak passwords using tools like John or rainbow tables be considered "best practice"?

Absolutely, in fact, many Linux distributions do some level of this out of the box. You should look at pam_cracklib, which applies a number of tests to a new password before accepting a change. Is it the same as the old one? The old one reversed? Almost all the same characters as the last one? Does the password exist in the dictionary you've specified to check against?

I find that Hal Pomeranz's review of pam_cracklib is an excellent place to start. He rightly points out that it isn't well documented, which makes it harder for administrators to use it to protect their sites, and lays out a simple guide to make it make sense.

That covers preventive maintenance for good passwords, which is definitely "best practice". Another procedure some follow is active cracking, where the admins will run John the Ripper against their own systems and, when a user's password is cracked, they force the user to change their password. This might be done on an ongoing basis, or on a scheduled (quarterly/semi-annual/annual) basis. There are some issues to be considered before choosing to do this; do you want your admins knowing user passwords as they get cracked? Do you have a safe place to crack that an attacker can't gain access to? If you make users update passwords as fast as they get cracked, will that be too intensive? ("All users must change their passwords on days that end in 'Y'...)

Finally, your question focuses on the password strength. For defensive purposes, I urge you to also pay attention to password hash encoding. Unix/Linux passwords may be hashed with DES, MD5, or Blowfish; it is configurable on a system level. Many systems use the oldest and most common algorithm, DES, which is trivially cracked. If you can change your system's settings and your passwords to MD5 or Blowfish, it will become much harder for attackers to crack your passwords, even if you user chooses "Pa$$w0rd" as their password.

Improve this answer
5
  • using pam_cracklib or pam_passwdqc is absolutely best practice, thing is, they let through passwords that are not secure (like "pa$$w0rd!"). I consider it safer for admin to know the user's password for few days than leave the easy password as valid in the system. As for the last point: If I have windows machines I have to use NTLM hashes, I already use SHA1 hashes for UNIX authentication.
    – Hubert Kario
    Commented Aug 14, 2011 at 17:38
  • 1
    And you can, and should, automate cracking-based password automation to the highest level possible. Make a script attempt cracking and, if it finds a password, email the user and discard the password. This way the admin doesn't need to know.
    – jcrawfordor
    Commented Aug 16, 2011 at 7:14
  • Mailing password to the user in clear is illegal in my jurisdiction. Configuring it to use S/MIME encryption for 40 or 50 users isn't worth the hassle. Anyway, direct call to the user in question will be more effective.
    – Hubert Kario
    Commented Aug 16, 2011 at 9:28
  • Using SHA1 hashes will help avoid pre-image attacks (compared to md5) but that's not really your concern with a password database. Since they're just as fast as md5, they won't help you if your password hashes get taken. Luckily, the Unix crypt implementation is more secure than NTLM hashes by default; although real durability enters the picture when you switch to bcrypt, pbkdf2, or scrypt.
    – user502
    Commented Aug 17, 2011 at 12:34
  • @user502: yes I know all of that. But that does not help me if I have to use NTLM hashes too (like the 90% of all businesses out there). I don't have to care for UNIX password security (with its salted crypt or SHA1) if I have a mile wide hole in my defenses, now do I? For an attacker to get NTLM passwords, he would need to have access to my network. To have UNIX hashes, he would need to have root access to LDAP or domain controller.
    – Hubert Kario
    Commented Aug 20, 2011 at 13:43
1

Something to consider is psychology. Instead of prompting your users for a password, prompt them for a pass phrase, or prompt them for four passwords and enforce 20 characters.

It's always better to provide your users with positive guidance that leads to a desirable outcome than punishing them for failure to comply with the mystery requirements.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .