Post: On Authentication
I have a confession to make: I don’t like passwords.
To clarify that statement, I don’t like seeing passwords. A row of asterisks is fine: perfectly happy with that. A row of little black circles is even better: after all, it’s prettier. But looking at a monitor, sheet of paper or Post-It note and seeing a password staring back at me sends a little shiver running down my spine. Some cultures are reputed to believe that taking a photograph of someone steals a little piece of their soul; I tend to think much the same about writing down someone’s password. “Keep it secret”, as they say; “keep it safe”.
This, of course, is pretty much the standard geek attitude to passwords: they are to be guarded with one’s life. Offer a geek a Mars bar for their password, and they’ll offer you an angry stream of verbal abuse. Or possibly a lecture on social engineering and user account security. Knowing most geeks, it’ll probably be somewhere between the two.
All of this leads up to a discussion of two things: the OAuth protocol which aims, amongst other laudable goals, to help safeguard users’ passwords, and the distinctly unnerving trend which Jeremy Keith has christened the password anti-pattern, which really doesn’t.
OAuth?
The problem OAuth addresses is, on the face of it, a simple one: if I am using an application, how do I allow another application to access some amount of my private information, or act on my behalf, without leaving myself wide open to abuse? In point of fact, OAuth is far from the only protocol to address this problem, nor is it, strictly speaking, a new one; it’s more of an attempt to standardise the ultimately similar, but subtly varying, authentication protocols from the likes of Flickr, Facebook and Upcoming, and to tease out a common standard protocol from the aspects they share, while remaining abstract enough to give individual implementers the freedom they need to tailor the system to their own needs. (For the record, when I refer to “OAuth” in the remainder of this article, I most likely mean “OAuth and the similar protocols on which OAuth is based”.)
Much as the problem is ostensibly simple, OAuth’s solution is also based on a simple premise: keep control as close as possible to the user. When an application wants to access your account (a “Consumer”, in OAuth-speak), it first asks the application holding the account details (a “Service Provider”). The consumer then directs you to the provider’s site, where you get to authorise the access. There’s a whole swath of cryptographic gubbins behind the scenes which I don’t yet profess to understand, but that‘s the basic premise of OAuth in a nutshell. So far, so shiny.
Where it gets really interesting is in two of the main implications of this method: granularity and revocation. Depending on the way the provider has chosen to implement OAuth, different sets of permissions can be granted to different consumers. By way of example, you’ve probably heard of Moo and their facility to pull photos out of your Flickr stream and onto business cards. Because of this, I have chosen to allow Moo to retrieve information about my photos, my sets and my tags. They cannot, however, change anything. After all, why should they be allowed to?
Revocation is another nifty consequence that naturally drops out when using the OAuth-style approach. To carry on the previous example, should I ever decide, for any reason, at any time, that I no longer wish to deal with Moo, I can simply log into Flickr and revoke their authorisation. The most notable side-effect of this is that it becomes much less scary to allow another application to poke around in my account, since I know, to some degree, what they can and cannot do, and I know I can stop them at a moment’s notice.
The OAuth site gives two particular real-world analogies for this situation: valet keys for your car, which will only allow the car to be driven a short distance, and credit cards, which you authorise by signing a slip of paper or typing in your PIN, rather than giving the PIN to your waiter and hoping he doesn’t nip over to the nearest cash machine to clear our your account. To use another analogy, imagine you needed someone to come into your house and fix your boiler. Now imagine you could give him a special key which would allow him to enter your house, fix the boiler, make himself the obligatory cup of tea, and nothing else. Then imagine the key would disintegrate once the work was completed. In the real world, this will likely remain, for the foreseeable future, in the realms of science fiction and over-excitable documentaries with “Of The Future!” in their titles; in the world of computers, however, we have it right now.
If only we’d had a bit more of it a few months back.
The Password Anti-pattern
While this is all well and good, it would appear to a pessimistic observer that it may all have come too late. You see, many of the applications with the most useful information either haven’t yet implemented OAuth-style APIs yet, or hadn’t at the time that particularly influential consumers (Facebook being a textbook example) wanted access to said information. Yes Twitter, yes Google, I’m looking right at you. In the absence of such a solution, the consumers adopted the pattern of asking people, on their site, for the username and password on the other site.
I’m not sure I possess the words to describe how mind-buggeringly bad an idea this is. To return to the boiler analogy, the equivalent situation is that you need someone to come into your house and fix your boiler, so you cut him a copy of your house keys. If anyone asked you to do this in real life, you would tell him, in no uncertain terms, where he could go and what he could do to himself when he got there. You would then phone the police in rather short order. This, though, is what you are doing every time you put your username and password for one site into any other site: you are trusting them, not only to be kind enough not to shaft you, but also to be responsible enough and smart enough to keep your password completely secure. At all times. Forever. As if that weren’t bad enough, an overwhelming majority of people who use a particular password in one place will use it in many, if not all, of the other places where they need a password. So your house keys also work for your car, your holiday cottage in the Cotswolds, your office and perhaps even your safe deposit box at the bank. How many people would you trust with a copy of those keys?
Unfortunately, the cat is now out of the bag; the horse has bolted and is prancing happily around in the fields, merrily shitting on everything it sees. People have seen that they can enter their username and password, letting the application they’re using sort everything out for them and, as shown by the reaction to the Pownce iPhone app, many are rather taken aback when required instead to perform an abrupt context switch, and would prefer it the other way. You know, the mind-buggeringly bad way. The “copying your house keys” way. That way. This is a big problem.
Well, crap
So is there anything we can do about it? If so, what? I’ll be honest and say, right here and now, that I don’t know. It could be that it’s a case of saying “Look, we know what’s good for you, so we’re going to do it the right way and you’re just going to have to play ball”. It may be that the number of OAuth-style services will increase over time, and that this will become the “normal way” of doing things. However, if people are given a choice between a service which bounces them off another website and a service where they can enter a password then and there, they would seem to have shown their preference already.
It’s possible that the solution is to educate people, to explain to them why giving someone free rein over your account is a bad plan. It may even be that the nature of the password anti-pattern will accomplish this for us, as a few highly-publicised cases of people having their accounts hijacked may jog the public out of thinking it’s something that happens to Other People. It’s not a nice way to move things forward, but if it serves to make the web a safer place, it just might be worth it.
It may even be that we have to give people the choice themselves: security-conscious users can use an OAuth-style approach, while those for whom convenience is an absolute priority can use their username and password and accept the risks. Would this work as a stop-gap solution? I don’t know, but I wouldn’t hold my hopes too high, given the laziness of developers, the tightness of deadlines and the paradox of choice. Give people a choice as to which authentication method they want to use, and a significant number of them will probably just choose to go elsewhere, where it’s simpler.
Whatever happens, this is all happening and this is all changing right now,
and we, the developers in the thick of it, hold the power and responsibility
to determine how this whole mess situation unfolds. I’m
not sure whether that’s comforting, exciting or terrifying. Probably it‘s all
three.
In his article, Jeremy says that the password anti-pattern “teaches people how to be phished”. Simon says on Twitter that the password anti-pattern “has taught users to be phished”. I would say at least one – probably both – of these statements is true.
Let’s see what we can do about that.
Address book imports are the MOST criminal of this. “Enter your email and password into our site, and we’ll retrieve your contacts and see who you already know that is using our service.” I fought long and hard to say “we can’t promise the 3rd party isn’t reading your email and getting your financial data, but gosh darn it, we’re paying them money not to screw us.”
I haven’t a clue how to remind people that WE shouldn’t be complaining when people type our password into someone else’s site then.
I have learned through the years that the best men out there are the Geeks and Nerds, stand proud sir, you are in a class with the best of the best, trust me. Have I ever lied to you before??? hugs; Lisa
How about a Twix?
Reminds me of the work I did upgrading PC’s at my Dad’s work. I told one of the employees that I would need him back in about an hour to log on so I could restore all his settings etc. He replied that I didn’t need him, his password was written on the whiteboard in his cubicle. I gently explained what a stupid idea that was, and left. Next day when I came to work on his machine, I was pleased to see the password had disappeared. I was somewhat bemused to read instead a notice which said “Password on post-it in top drawer, for security”. The draw was of course unlocked…