Alrighty, this will be a fairly light post (in terms of my own applied analysis)... and, apologies as it's a wee bit behind the curve on various news pieces in the past couple months (I'd intended to write this in early January - oops!;). Please note that this post applies only to user passwords, and it does not apply to system and database password maintained within various environments.
Main Thesis: All this password analysis on compromised user password databases is fairly absurd. The breaches themselves are not generally the result of user password being compromised. As such, the time spent analyzing these passwords is largely a waste of time because it does not appreciably represent much risk to businesses; especially not to those that were compromised.
If this sounds like a topic I've discussed before, then you're right. I wrote about in about 18 months ago in my post "Password Complexity Is Lame." What got me going on this topic (albeit, back in Dec/Jan) was analysis of the STRATFOR compromise. much adieu was made of the passwords some folks were using (e.g., see this piece), and yet it was just inane mainstream media bologna. As per usual, users were assailed for their password selections, and yet who cares? What harm was really caused?
Rather than fully rehash everything that's been said, let me start out by wading through several of the pieces written...
Raf Los summarized the problem for well in his piece "Are weak passwords to blame for your data breach?". It's a simple little diagram, but the fact of the matter is that it's the right fundamental question from a risk analysis perspective.
Rob Graham at Errata Security had a decent post talking about his 3-tier password reuse approach. In particular, in talking about choosing his "first tier" passwords, he puts an emphasis on complexity saying they "...should both be very complex, as well as wholly unrelated to any other accounts." Unfortunately, this is just lame. "Complexity" is a red herring. Ultimately, the two main factors that really matter are 1) requiring a long password (16 chars or greater), and 2) not limiting the character set of the password. Beyond that, everything else will inevitably lead to other problems.
Ultimately, Bill Brenner got to the heart of the matter in his CSO "Salted Hash" blog post, "Passwords are better off dead" when he points out the main problem: that passwords are still the primary form of authentication! Indeed, what all this user password analysis overlooks is the major problem that we lack a truly viable, mainstream(able) alternative to passwords. Until we solve this problem of finding an alternative, we'll continue to have these inane discussions on password strength/complexity.
The New School guys add, in a post titled "New School Approaches to Passwords", saying: "We need to agree that passwords suck when they're not properly cared for, and that caring for them is hard. So we need to assume that passwords will tend to be poor, reused, etc, and develop methods to deal with that. Most of our mechanisms today punish users." Why do we punish users when they're not responsible for the primary defense measures? For that matter, why are we punishing or maligning users for failing to treat information risk that isn't theirs to manage? It doesn't make sense.
The root labs rdist blog made an excellent point in their post "On the evolving security of password schemes", saying: "Password security is a difficult problem, especially with a varied user base. However, most admins focus too much on increasing entropy of user choices and not enough on decreasing the attacker's guess rate and implementing responses to limit their access when they do get a hit." Which is to say: the primary defense methods really have nought to do with "password strength/complexity."
In a different post, The New School folks found an interesting paper around the same time that called into question the related password-management practice of password expectation. In a nutshell, a real study concluded that enforcing password expiration isn't all that useful, and may actually reduce the security (or increase risk). That goes along with my post that reminds us that considering our primary defense mechanisms is probably more important than assessing the individual strength of the passwords themselves.
Lastly, in a separate study (and unrelated to the STRATFOR analysis reports), the Light Blue Touchpaper blog posted an interesting analysis of password brute-force attack patterns that they observed over a 2-week period. As with the paper on password expiration, this actual research was interesting because it observed common attack patterns, and once again highlights a number of key issues. One of the more interesting observations was that some guessing attempts used fairly complex, but specific, strings, with the theory that someone was using a sizable database for guessing (e.g., you can get a database of >2 million passwords that includes the "500,000 most popular passwords").
Wrap-Up
A few quick take-away points:
* Password strength/complexity is a red herring. Length and a large available character set are typically the only important attributes.
* The primary defensive measures against password brute-force attacks typically have little, if anything, to do with password strength/complexity.
* Analysis of user passwords is a red herring. Those passwords almost universally have nothing to do with the cause of the compromise.
* Even seemingly mundane and ok practices like password expiration can be detrimental.
* Password reuse may be problematic unless using a tiered approach aligned by your own personal risk tolerances.
I only expect the data to continue building that supports these conclusions. Now, if we could just find a viable, universal replacement for passwords...
Update (2/7/12): Someone posted this article from Nov 2011 on twitter, which talks about the "top 25 worst passwords"... this kind of reporting is just plain stupid as it lacks context and useful analysis. Just because a password is "weak" does not make it "bad" - it all depends on where it's being used, and the potential impact of it being guessed. It's the same point that several made about the STRATFOR passwords.
Ben, why don't people talk about account lockout mechanisms? Strong passwords are only really useful in lengthening the amount of time it takes for a brute force attack. As you alluded above, the real solution to that is simply to lock out a user after some number of failed attempts. I'm not sure why we spend so much time on password strengthening. Is that your point as well? I wish I'd seen your Aug. 2010 post earlier - there were a number of times, I'd have pointed it out to folks. So, what am I missing? Why is there so much focus on it?
Hi Matt,
Yes, I think you've captured my point. If you go back to my Aug 2010 post, you'll note that I include lockouts in the list of common defensive measures. Ultimately, what all this password analysis neglects is useful threat and attack modeling considerations.
As for why password analysis is so popular... I submit it's part of the "users are stupid" meme that is so popular in the industry. We can't invent a solution, so we push responsibility onto the users, and then we mock them for our own shortcomings. Hardly fair or useful.
Thanks for the comments!
-ben
Password lockout is great for stopping online brute force attacks, provided that the values for lockout count and the activity window make sense. If for example you have a lockout count of 3 tries in 5 minutes, this is less effective than 3 tries in 30 minutes. The trade off is calls to the help desk. Too big of a window and your help desk costs go up quickly. If the lockout activity window is too small then an attacker can just spread out the time between the guesses (try one per minute). This would still statistically take centuries to brute force a password with all possible combinations, but in reality the top 10,000 passwords could be tested in 7 days without a lockout event. The hit rate for the effort in this case may well be worth it.
Also this does not take into account offline brute force attacks. If I am in a position to capture password hashes then I can try thousands of attempts per minute. In this case Salts and entropy are your best friends (and if you are using AD then passwords over 15 characters in length).
It's OK, next year is the year of PKI. You won't need passwords.
In most cases, it's counterproductive to lock a user out for five minutes, let alone 30. Long lockouts do more to increase the number of calls to the help desk than to increase security. Just limiting password attempts to one per second drastically reduces the number of attempts that an attacker can make. Increasing the delay to five second after five or ten failed attempts would make online brute force even less useful without causing undue problems for legitimate users who have trouble remembering their passwords. If you really want a hard lockout, implement it after ten or twenty attempts rather than three.
I realized that I misread Lostfocus' comment, but my point stands. I like delays much better than lockouts in order to balance security vs support costs.
Mostly agreed with your comment. Two follow-up points, though:
1) Setting a long length requirement (and only that) will address the current list of trivial 10,000 passwords. This will presumably lead to a new list of top 10,000 passwords, though maybe not. That said, who cares? What's the cost of a compromised end-user account? Remember, we're talking consumers here, not enterprise.
2) If an attacker is able to compromise the password database, then I submit that you have larger problems than password strength (a point covered in my original post on password complexity).
cheers,
-ben
This "calls to the help desk" theme assumes that there *is* a help desk to call. Show me a Google support phone number for gmail, etc. In enterprise space, the balance is different, but the same defensive measures apply and are important to note because they still provide an alternative mechanism to password strength/complexity.
I totally agree with your argument here about password length and complexity being pretty low on the priority list of authentication issues. I would just like to mention a couple randomly related thoughts that may be covered in some of the links or previous posts you made -- but I have not read them all yet (sorry).
To me, often glassed over in the "weak or infrequently changing passwords are the problem" argument are the issues problem related to lost passwords. One thing I have notices with many of the systems that I use that require various password hoop jumping is that the "lost password" process, more time than not, is much weaker than the authentication process it is augmenting. Most are nothing more than an automated email telling you the password you chose or, slightly better, resetting your password and giving you a link to change it. Even many of the better ones appear to me to be susceptible to social engineering attacks through the lost password process. Attackers will focus on the weakest link in the chain and this link, often times and especially from the media hype you mentioned, is overlooked.
Second, a problem with automated delay or lockout logic, while I think is a requirement for strong authentication, is also a point for becoming a contributing factor of a DoS attack that this vulnerability has to be addressed or at least acknowledged. It would not be too difficulty for an attacker to walk through a user database and force delays or lockouts of everyone -- possibly cascading into lost password issues previous mentioned.
In looking into password alternatives, I think this matrix from Lightbluetouchpaper is useful. I like how thoroughly they considered the various factors that play into each solution & let us visually compare them.
http://www.lightbluetouchpaper.org/wp-content/uploads/2012/05/matrix.png