Sympathy for the Devil - Cormac Herley's Password Research

Back to back devil posts. Last post was called Friend of the Devil, the Shostack Code. Now we are into Sympathy for the Devil and Cormac Herley's work. Don't read into the devil part too much as a company thing, just because Adam Shostack and Cormac Herley both work at Microsoft. Its actually a commentary on dealing with devils - governance (Shostack and Threat Models) and passwords (Herley).

Passwords feel like dandelions to me. Every year, you try and root them out. Crawl around in the mud, or maybe you are a technocrat and invest in a Dr Seuss-like gadget to try to pull them - whereupon you find that you get one out of three.

Or maybe you engage in the time honored tradition of outsourcing and pay neighbor kids (future Big 4 consultants?) to do it for you.

Anyway, they're annoying, they make your lawn worse, and they never fully go away.  Like I say, they remind me of passwords.

Everyone knows the issues, yet here we are. Cormac Herley and company ask - If We're So Smart Why are We Still Using Passwords? The answer has something to do with usability, as you might have guessed, as well as incentives.

Exploring the intersection of usability and security in "Where Do Security Policies Come From?", the paper reverse engineers the password policies of most of the Web's popular sites and examines minimum strength, expiration (almost never), and commercial pieces such as whether ads are used or not? 

And following that Cormac Herley and team get even more heretical with a Research Agenda that Acknowledges the Persistence of Passwords. (Side note to Paul Madsen - is it possible to have a Cloud Identity Summit t-shirt with "I am shocked, SHOCKED to find passwords in this establishment!" ?)

The agenda lays out the following goals -

• Ending belief that passwords are dead
• Understanding strength online, offline
• Better policy support and tools
• Prioritizing competing requirements

As someone who has spent many years pulling dandelions, I would love to poke holes in this work and say that passwords are beyond help, but as someone who lives in the real world - passwords are just about the most persistent thing in security. Instead of treating them like the technology of yesteryear and they always will be, perhaps its time for a hard look at the research questions above. I do not see how anyone can argue with the first bullet point and if that's the case then the following three become much more interesting.

Passwords are "dead"

As much as we might wish for this, its not the case. Even with all the work on identity systems, the initial authentication 99% of the time is still a good, old fashioned user name and password. Yes all manner of identity protocol geekery may exist behind it, yes passive fingerprinting, and other backend things happen, but the password remains.

Understanding strength

Key distinction here between online and offline attacks. One case that the agenda does not go into is that this is a major point in mobile where offline attacks are to be expected when you have lost/stolen mobile devices. Password storage is not only something that occurs in data centers. While we're on the topic of mobile, the overall strength of mobile passwords is almost always way lower because the password rules are relaxed to not tax people's thumbs too much.

Better policies and support tools

Makes the case that password aging enforced reset is a usability disaster and do not deliver much in the way of security gains - an attacker who knew the old password could guess the new one 41% of the time off line and 17% of the time online. 

The paper makes the case that more is to be done on password managers (again we circle back to off line attacks). Today, these are mainly consumer tools but enterprises do kick the tires and sometimes adopt password managers. If you embrace the notion that passwords are not going away, they should be on the list of tools for certain scenarios.

Prioritizing Competing Requirements

Suggests building a checklist out of the highest ranked attacks in the threat model and using it to identify where passwords are the best fit solution. Hard to argue here.

I am not sure that passwords are the best fit solution in many of the scenarios where they are currently deployed, but I am very sure that they will still be used in those scenarios for many years. If that's the case, its time to revisit the assumptions around them. It does not mean that work on other identity protocols stops, I mean I am no wine guru but I know the difference between Cotes du Rhone and dandelion wine. Passwords have a role to play in many systems today and that will persist, and it can be done better than it is today.

Update: Eve Maler drills down on usability and seucrity. 

Comments

[Cormac Herley]

Gunnar,

Thanks for the flattering write-up. Glad you find the stuff interesting. Most of the time people start talking about passwords it feels to me like I stepped through a portal into an alternate universe.

For all the talk about how urgent it is to get rid of passwords, most of the attempts to date seem unserious. For all the talk about how important usability is, there's been more effort put into bullying users into treating low-assurance applications as high-assurance than into coming up with usable alternatives. We'll get there eventually, but we're probably going to have to get a lot more serious first.

[gunnar]

@Cormac - of "bullying users into treating low-assurance applications as high-assurance" -- trenchant. there is no other word for that summary.

I would characterize the overall approach a bit different. Serious, as in seriously haphazard with a few exceptions.

[gunnar]

@Cormac - one more - how many legs does a three legged dog have if you call a tail a leg?

answer: three. just because you call a tail a leg doesn't make it a leg.

Related: What level of assurance does a low assurance solution have if you call it high assurance?

[Cormac Herley]

@gunnar

Yes, there may be a "No true Scotsman" elastic qualifier here. What I mean is that if we assume the value of the asset is infinite, then "do this impossibly long list of things and neglect nothing" seems reasonable. However, while most people acknowledge that for low value assets this isn't appropriate, nobody is explicit about which of the impossibly long list of things we can neglect.

So we acknowledge the exception, but don't handle it. In pseudo-code:

If (value is infinite) then
do everything;
else
{code-block we decline to write}
endif

We're so desperate to avoid writing or thinking about that code-block that pretending everything has infinite value is the easiest way out.