Comparison of Password Complexity Rules

This topic approaches a religious debate.  Two-factor authentication like the previous poster mentioned is ideal- you're required to *know* something and *have* something physically, so compromised password is useless without the smart card.

You do need to consider the tradeoff of having more complex passwords as doing so often results in end users writing them down and putting them on a sticky note on their monitors.  I do like the idea of not allowing users to use dictionary words in their passwords as there are plenty of dictionary-based attacks hackers can use.  

Also, implementing even a modest lockout policy (10 failed guesses, 15 minute lockout) will slow down brute force attempts.  The downside to lockout policies is that you must consider the possibility of them being used in a denial of service.

I have something else to add to audits - which has annoyed me for a long time - sorry if it is off-topic.

It seems when it comes to IT that we are always expected to guarantuee everything using technology. Why is that? It can't always be done, and it's not always feasible. You should tell your auditor: It's our policy and our users are required to do it, otherwise IT'S THE USER'S FAULT for not doing it. That's why it's a policy - they MUST stick to it. If they fail to do so, and their account gets cracked, then we can take measures against the responsible users.

Now before you laugh at me... Image there is a policy that HR needs to file all printed confidential documents in a locked room. Nice policy, right? But there is no way to MAKE SURE they do it. It will be the responsibility of the HR person to do it right, and we trust them that they do it. So why is this acceptable, but in IT everything needs to be done for the users, like they are little kids and not responsible adults.

If they insist then ask them if you should take all office keys away from everybody. If you don't do that, they could make copies or lose the keys, thus providing intruders physical access to your office.

I hope I get my point across. Some things we just cannot guarantuee, and there will never be absolute safety, not in IT nor anywhere else, and I wish all those little auditors, policy-makers and security "specialists" would come back to earth and real life for a while. I think they are just afraid of it because they don't understand it.

:)

Well, to be fair, lockouts only affect ONLINE brute force attacks.  Take something that chews against a hash table of Windows passwords (see the L0phtcrack, john the ripper, ophcrack, etc), and it doesn't matter if you have a lockout or not.  Add in Rainbow tables, and you take a lot of the pain out of brute force anyway.

I was really just looking to bolster my argument with something approaching published / peer-reviewed saying that my point had merit.

I've definitely seen your point written in several places.  Off the top of my head I'm not sure where I've seen this but here's a start for some reading.

SANS InfoSec Reading Room - Authentication
http://www.sans.org/reading_room/whitepapers/authentication/

These are papers written by SANS certification qualified individuals.  

I always viewed the offline attack as more of a theoretical problem, though... If you already have access to the SAM or Active Directory to a level that allows the usage of such an attack, the attacker wouldn't need passwords anymore, because he already is domain or local admin and there's a dozen easier ways of getting the passwords then (or they are no longer required). So I think a lockout policy helps a lot.

http://csrc.nist.gov/publications/drafts/800-118/draft-sp800-118.pdf

At least 3/4 is pretty standard.  If that isn't good enough then get a smartcard and use certificate logon.  For some products you can set the password policy to require 2/4, 3/4, or 4/4, or any specific combo.  There are 3rd party apps I'm sure that would require 4/4 but honestly I think it would be wasted money.

Password length is more important.  Just because only 3/4 is required doesn't mean that anything becomes not available.  You can still use all 4 if you like, you just don't have to do more than 3 is all - there's nothing saying which 3 it will be (granted upper/lower/number will be prevalent).

If you have a 10 character password you're generally ok, 12 is pretty good and 15 is US military standard.  I'm sure there are better examples than this, but here's a link for a USAF academy (I also know a number of folks in various military groups here in US and have all stated 15 char minimum password length or use CAC).
http://www.au.af.mil/au/awc/dl/index.htm

Nice little article:
http://infoworld.com/d/security-central/test-strength-your-password-policy-437

From the second page in that they offer a link to this:
http://www.infoworld.com/sites/all/themes/ifw/downloads/passwordcalc096.zip

This is a spreadsheet that will help you calculate the strength of your password against being cracked.  Its pretty neat and I think may be just what you are looking for.

4/4 is nice and all, but extendingthe necessary length is even better.  2 factor authentication such as certificates on a smartcard or USB smart token are better.  Adding biometric to that for 3 factor (something you have, know and are) =  best.

I like the comment of the former auditor above. Must be one of the few who has a clue :)

Now in all honesty, if this is your policy the auditor is just doing his job. It seems to me that this is an internal policy, so while this may not help for this audit I think your best approach is to get the policy updated to match reality. Just put in there what you already do - the difference in security is insignificant so whoever put that policy in place should be satisfied, and during your next audit you will have one issue less to worry about.

It gives me a way out, but it doesn't really address what I was looking for -- an academic review of the relative desirability of 3/4 versus 4/4 in password complexity rules.  I'm stuck with what I'm stuck with.

>> I like the comment of the former auditor above. Must be one of the few who has a clue :)

:)

Part of the issue with auditors usually comes down to the fact that this is what they are.  It is their job to audit you against your written policy.  If your policy is invalid, then you're going to get nailed for it anyways.  Its not their job to say that your policy is invalid, unless it conflicts itself.  Sometimes the solution is to change the policy as the mitigation plan.  We've had quite a few of these things that just didn't make sense that we inherited - they got rewritten in the spirit of the concept and made viable.

When discussing if something is possible or not that's another story.  Then it comes down to the experience of each person.  The question is if it is a discussion regarding viability or a discussion regarding policy adherence -  understand these are two completely different discussions.  If something is generic or gray, you can discuss with the auditors ahead of time for a ruling so you don't get bit, but it is not their job to write or change policy - only interpret and observe for compliance.

What opened the door in this specific audit is that the auditor in question declined to cite violations in a few other areas where the policy was more prescriptive than the regulatory standard, even though the policy did not completely meet the requirements of the standard.  In other words, because the policy created a greater level of security than the standard would have, he allowed the difference in our favor.  In the password standard, the regulation says "alpha, numeric, and symbol", while our policy reflected the passfilt 3/4.  The violation is still both "potential" and "alleged", so there is time to convince the auditor to fall the other way, but the complience officer, who is a lawyer (not an IT guy or mathmetician) , wants a some authentic, acedemic, and best-practice type arguments so he can plead the case.