Shaggy Dogma: Passwords and Social Over‑Engineering

Recently I presented at the CFET (Cybercrime Forensics Education & Training) conference in Canterbury, in the UK, on password and PIN selection strategies, an ongoing research interest. To be more precise, on this occasion I was talking about revaluating the way we educate computer users about good password/passphrase/passcode selection practice. (I’m afraid there wasn’t a paper to go with the presentation, but there’s a very PIN-oriented paper I presented at EICAR a couple of years ago here: PIN Holes: Passcode Selection Strategies.) (I’ll probably return to the whole education and strategy issue on the ESET blog in the near future, but right now I want to look at a very specific issue.)

Hardly had I left Canterbury before my attention was directed to a paper by Dinei Florêncio and Cormac Herley of Microsoft Research and Paul C. van Oorschot of Carleton University, Ottawa, which, according to The Register ‘shot holes through the security dogma’: namely, a paper called Password portfolios and the Finite-Effort User: Sustainably Managing Large Numbers of Accounts.

So what was this shaggy dogma story? Well, let’s go back to an extract from that presentation.

Fernando Corbato, the MIT computer scientist who is widely credited with pioneering the use of the password as a means of logging into a computer, says passwords have now become “kind of a nightmare.” Some might call that payback…

Corbato said in an interview with Wall Street Journal’s Digits Blog that he himself had around 150 passwords, and now committed security sins such as writing down a “crib sheet” to remember them all. Presumably written on the world’s biggest Post-IT, stuck onto a very large monitor.

Security researchers usually suggest that you use the strongest possible password, change it frequently (and certainly if there’s any possibility of a compromise), and don’t ever re-use the same password between two or more services. Even if you have fewer than 150 passworded accounts to maintain, it’s likely that you have a lot of strong passwords to generate, and remember, and you probably have to change at least some of them fairly regularly. But this ‘dogma’ is by no means irrational, even though there are scenarios (some of them all too common, like a server breach when the service provider drops the ball and an attacker gets access to a large credentials database) where your password is less safe than you might think or hope. Nevertheless, strong passwords/passphrases do, in the most favourable circumstances, represent a significant obstacle to easy compromise by an attacker. So is there a less onerous alternative? Well, yes and no. Password management software, for instance. But Florêncio, Herley and van Oorschot are suggesting something that sounds at first a little more radical.

They have presented a dense and detailed paper, well worth reading if you’re interested in the minutiae of authentication (and covers more issues than I’ve mentioned here). Indeed, if it had been available when I compiled my presentation, I’d certainly have made reference to it. But for the everyday user, it offers one simple and possibly useful idea, based on the assumption that some authenticated services are more important (or carry more risk) than others. Indeed, I don’t know about you, but I often find myself having to generate a username/password pair for a service I may never use again, and where authentication may actually be overkill in any case. At least from my point of view: however (for instance), a publisher might want to track who accesses a particular document by requiring each person to create an account. (And in fact that’s a common enough scenario for a professional researcher.)

The paper concludes:

We have explored the task of managing a portfolio of passwords. A starting point for our analysis was the critical observation that to be realistic, efficient password management should consider a realistic suite of attacks and minimize the sum of expected loss and user effort…

… optimal grouping will put high-value accounts in smaller (or singleton) groups, and low-value accounts in larger groups.

They don’t say, as you might think from some reports, that strong passwords and non-reuse of passwords across accounts are always overkill. They do, however, seem to suggest that grouping accounts according to value (think in terms not only of value to you, but to a potential attacker) means that some accounts don’t require the same degree of authentication as others. For instance, you might have a standard memorable password that you might use across less important services. And in fact, I suspect that this isn’t an uncommon strategy. It isn’t one that finds its way into security gurus’ recommendations, however. Perhaps because it’s not always easy to define what constitutes low-value to an attacker (let alone an end user), and therefore to provide hard and fast rules about how to assign sites/credentials to groups. The abstract does offer:

… an optimal password re-use strategy in the following sense: for a fixed number of passwords, and a given set of accounts (thus effort is fixed), find how to group accounts to minimize total expected loss.

Sadly, that solution is presented in abstract terms that probably do not help much if you’re wondering whether to generate a password with optimal entropy for a given site, especially if you don’t know what password entropy actually is. (Simplistically, it’s a way of measuring how easy to predict a password is: in this sense, predictability might imply susceptibility to a variety of attacks – it’s more complex than a simple measure of randomness.)

This is not a trivial issue: if you’re prepared to accept that low value is the same as low risk and you don’t care whether your credentials for service n are compromised – even if that means that your credentials for x, y and z may also be compromised because they use the same password – you’d better be sure that

1. those really are low-value, low-risk services
2. there aren’t any high-value, high-risk services that might be at risk of secondary compromise. (For instance, when knowing your shared password might make it easier for an attacker to guess the high value service password even though you don’t use the identical password on the high value service.)

For a security specialist, it’s easier to suggest that – despite the inconvenience – you treat every service as high value (i.e. advise never to share), rather than try to define exactly how to group the passworded services you use and provide a lengthy explanation that covers all the edge cases with no possibility of misinterpretation. I can certainly envisage scenarios where services may be regarded as low risk and low value but the shared password might offer a clue as to what strategy was used by the same user on a higher value service.

Unfortunately, over-engineering is one of the ongoing problems with security education generally. And one of the reasons for that is that – as always – you can’t rely on every end user to interpret everything you say correctly, even if you express it as you intended.

David Harley
ESET Senior Research Fellow