Links

Today I spent an hour with a bunch of academics. Each of the panellists had to talk for a few minutes to set the scene. I decided to talk about the worst usability disaster ever, namely passwords.

The problem with passwords is that we pin all our security on them. Although I can imagine a future world where we pin our security on other things, like strong credentials, I still wonder how that world really looks?

In particular, when I buy the latest Mac, how do I get it all signed up with all these credentials? It seems to me that the only usable answer to that question is that I fetch them from the cloud. How do I do that? Ultimately, with a password of some kind. Yes, you can back it up with a dongle or something, but when I lose that, how do I get a new one? I call you and give you … a password (of course I include my mother’s maiden name, my postcode, my date of birth, the name of my first and most beloved hamster and all that other nonsense as passwords). And if I only ever do this every couple of years, how easy is it to persuade me to do it wrong? Pretty damn easy, if you ask me. And you did.

So, where does this leave us? Users must have passwords, so why fight it? Why not admit that its where we have to be and make it a familiar (but secure) process, so that users can actually safely use passwords, phishing-free?

The answer to this is deeply sad. It is because we have done a fantastic job on usability of passwords. They’re so usable that anyone will type their password anywhere they see the word “password” with a box next to it. Phishing is utterly trivial because we have trained the world to expect to be phished every time they see a new website.

Of course, we can fix this cryptographically – that’s easy. But let’s say we did that. How do we stop the user from ever typing their password into a phishable box from this day forward? So long as they only ever type the password into the crypto gadget that does the unphishable protocol, they are safe, no matter who asks them to log in. But as soon as they type it into a text box on a web page, they’re screwed.

So, this is why passwords are the worst usability disaster ever.

Anyway, now to the title. Suppose we get to this utopia, an academic suggested, we’d still be screwed because passwords don’t scale. Because, of course, we need a different password for each site we log in to.

Well, no. If your password is unphishable, then it is obviously the case that it can be the same everywhere. Or it wouldn’t be unphishable. The only reason you need a password for each site is because we’re too lame to fix the real problem. Passwords scale just fine. If it wasn’t for those pesky users (that we trained to do the wrong thing), that is.

Kim wants to save the world from itself. In short, he is talking about yet another incident where some service asks for username and password to some other service, in order to glean information from your account to do something cool. Usually this turns out to be “harvest my contacts so I don’t have to find all my friends yet again on the social network of the month”, but in this case it was to calculate your “Twitterank”. Whatever that is. Kim tells us

The only safe solution for the broad spectrum of computer users is one in which they cannot give away their secrets. In other words: Information Cards (the advantage being they don’t necessarily require hardware) or Smart Cards. Can there be a better teacher than reality?

Well, no. There’s a safer way that’s just as useful: turn off your computer. Since what Kim proposes means that I simply can’t get my Twitterank at all (oh, the humanity!), why even bother with Infocards or any other kind of authentication I can’t give away? I may as well just watch TV instead.

Now, the emerging answer to this problem is OAuth, which protects your passwords, if you authenticate that way. Of course, OAuth is perfectly compatible with the notion of signing in at your service provider with an Infocard, just as it is with signing in with a password. But where is the advantage of Infocards? Once you have deployed OAuth, you have removed the need for users to reveal their passwords, so now the value add for Infocards seems quite small.

But if Infocards (or any other kind of signature-based credential) supported delegation, this would be much cooler. Then the user could sign a statement saying, in effect, “give the holder of key X access to my contacts” (or whatever it is they want to give access to) using the private key of the credential they use for logging in. Then they give Twitterank a copy of their certificate and a copy of the new signed delegation certificate. Twitterank presents the chained certificates and proves they have private key X. Twitter checks the signature on the chained delegation certificate and that the user certificate is the one corresponding to the account Twitterank wants access to, and then gives access to just the data specified in the delegation certificate.

The beauty of this is it can be sub-delegated, a facility that is entirely missing from OAuth, and one that I confidently expect to be the next problem in this space (but apparently predicting such things is of little value – no-one listens until they hit the brick wall lack of the facility puts in their way).

Kim writes about minimal disclosure. Funnily enough my wife, Camilla, spontaneously explained minimal disclosure to me a couple of nights ago. She was incensed that she ended up having to “prove” who she was in order to pay a bill over the phone.

First of all, they asked her for her password. Of course, she has no idea what her password might be with this particular company, so their suggestion was she guess. Camilla surprised me by telling me that she had, of course, declined to guess, because by guessing she would be revealing all her passwords that she might use elsewhere. So, they then resorted to the usual stupidity: mother’s maiden name, postcode, phone number and so forth. Camilla said she was happy to provide that information because she didn’t feel it was in any way secret – which, of course, means it doesn’t really authenticate her, either.

Anyway, her point was that in order to pay a bill she really shouldn’t have to authenticate to the payee – what do they care who pays the money, so long as it gets paid? In fact, really, we want the authentication to be the other way round – the payee should prove to her that they are really the payee. It would also be nice if they provided some level of assurance that she is paying the right bill. But they really don’t need to have any clue who she is, so long as she can hand over money somehow (which might, of course, including authenticating somehow to some money-handling middleman).

But what seems to be happening now is that everyone is using identity as a proxy for security. If we know who you are, then everything else springs from that.

Now, if what you want to do is to determine whether someone is authorised to do something, then certainly this is an approach that works. I find out who you are, then I look you up in my Big Table of Everything Everyone Is Allowed To Do, and I’m done. However, and now I finally circle back to Kim’s post, for many, if not most, purposes, identification is far more than is really needed. For example, Equifax just launched the Over 18 I-Card. I hope Equifax got this right and issued a card that doesn’t reveal anything else about you – but even if they didn’t, clearly it could be done – and clearly there’s value in proving you’re over 18, and therefore authorised to do some things you might not otherwise be able to do. Though I’d note that I am not over 18 in Equifax’ view because I do not have an SSN!

Anyway, current deficiencies aside, this is a great example of where minimal disclosure works better than identification – rather than everyone having a lookup table containing everyone in the world and whether they are over 18, someone who has the information anyway does the lookup once and then signs the statement “yep, the bearer is over 18”.

But in many other cases identification doesn’t work at all – after all, the premise of the ID card is that it is supposed to improve our security against terrorists. But its pretty obvious that identifying people really isn’t going to help – you can work that out just by thinking about it, but even more importantly, in several recent terrorist attacks everyone has been very thoroughly identified but it hasn’t helped one bit.

And in the case of my wife trying to pay a bill, identification was completely without purpose. Yet everyone wants to do it. As Kim says, we really need to rethink the world in terms of minimal disclosure – and as I show above, sometimes this is actually the easiest way to think about it – my one area of disagreement is that we should not call this “identity” or even “contextual identity”. We need a term that makes it clear it has nothing to do with identification. I prefer to think in terms of “proof of entitlement” or “proof of authority” – but those don’t exactly roll off the tongue … ideas?

Way back when I wrote about The Neb. The basic idea here was that you can’t trust your PC, so you should have a separate trusted device (The Neb) which is used only for final authorisation of transactions – all the work of getting the transaction set up is done on the untrusted PC. The core point being that The Neb has to include UI, because the user cannot trust what their PC tells them the trusted device is going to do (this is why the often-touted smartcard is a crap answer to the problem).

Seems IBM agree – they’ve released a simple version of The Neb, called the ZTIC (Zone Trusted Information Channel). Also, you can watch a video.

IBM’s version isn’t quite the same as my vision of The Neb, though – in their case, all data is routed through the ZTIC, which tries to guess when you’re about to send something you might wish you hadn’t. In The Neb’s case, only the data relating to the final transaction is sent to The Neb, explicitly, by the server, which then displays it and, if the user agrees, signs it. Their version has the advantage of requiring the server only to start supporting client certificates (and refusing connections without them, I guess) but the disadvantage that what they intercept and display is bound to be somewhat ad hoc. The Neb requires more support from the server, but can’t get confused about what is going on.

Don’t worry, if we put all our data into central government databases, it’ll all be fine. Except when it isn’t. Our esteemed Prime Minister says

“It is important to recognise we cannot promise that every single item of information will always be safe because mistakes are made by human beings. Mistakes are made in the transportation, if you like in the communication, of information.”

in the aftermath of yet another ridiculous data breach: this time, people’s passwords to the Government Gateway on a memory stick dropped in the road.

Perhaps it is uncouth to point this out, but … if the system had been designed by people with any security clue whatsoever there would have been no passwords to put on a memory stick in the first place.

I notice that Gordon thinks the contractors in this case (Atos Origin) are responsible and action should be taken against them (though how he squares this with his statement that such events are inevitable only a politician can tell you). Well, sure. But why is he not taking action against the morons that designed and approved a system that made it possible for Atos Origin to have the passwords in the first place?

My theory? Policy makers think that it is beneath them to actually understand the technologies they make policy about, or to consult anyone who does. So, it has not occurred to Brown or any of his advisers that this is actually an avoidable error.