Tag Archives: oauth

Posted on
by

It is the second time in as many days that I’m having to log into things and change passwords because of some less-than smart design decisions various web companies made when implementing their password database (looking at you Linkedin and Last.FM).

While these companies have clearly made a dangerous snafu, lets not be overly harsh on them. There but for the grace of god go all software developers. The real problem is passwords, and until we find something better, this kind of thing will keep happening.

Lets look at it from a UX viewpoint as well a security one for a moment, because they’re both linked. People, myself included, are phenomenally bad at creating secure passwords and remembering them. Predictably enough, this results in the vast majority of users using one memorable (but as a result easily guessable) password for everything, and/or writing all their passwords down somewhere… both things that are a bad idea from a security point of view and often elicit derisive snorts from security professionals clearly blessed with an eidetic memory.

Moving past Username and Password

Computers should adapt to humans, not the other way round. Isn’t it time we stopped wasting time trying to patch a clearly broken system and build something else?

This is of course much easier said than done, and the two current alternatives to username/password authentication available – OpenID and OAuth – are not without their issues.

OpenID is nice and decentralised, but the UX is just awful. Sign in with a URL? Try explaining that one over the phone to your mum.

OAuth has the benefit of being super super easy for the user (one or two mouse clicks to log in), so long as you’ve got an account with a given site’s blessed identity broker (for all practical purposes either Google, Facebook or Twitter). This model nudges towards a centralised identity model which I find very uncomfortable.

This centralisation raises new issues of catastrophic single points of failure. Not only do you have the issue of the service being a prime target for crackers, you also have a far more insidious and arguably more likely problem, basically, what happens when the identity broker you use for your 1000s of accounts goes out of business?

Not to mention, all three of the main identity brokers still fundamentally identify you with a username and password. Google and Facebook have added second layer authentication to their accounts, but Twitter is yet to implement anything (so if you have a twitter account and use it for authentication anywhere make sure your password is really really good).

So, what can we do to make this better?

Myself, I’d like to move to some sort of two factor authentication (combining something you have with something you know), at least for really important accounts. More and more people have mobile phones so perhaps something similar to the Google authenticator model or SMS code authentication for new machine sign-in would be a start.

Whatever we use, it needs to be decentralised, secure, and fundamentally easy for people to use. Because if whatever fancy solution we come up with provides a barrier between the user and what they want to do, it will be useless. People will just work out ways of circumventing the security in order to get things done, or simply not use the service at all.

Today, the most secure password-protected system you can ever build can be defeated by one forgetful user and a post-it note.

Posted on
by

Recently – both in my roll as a developer on the Elgg project, and as one of the organisers of Barcamp Transparency – I have found myself having to sign up for a whole bunch of accounts for various sites.

Each one asks me to fill in a profile, and each time I end up repeating myself. I am sick of it. This is the kind of thing OpenID was developed to partially solve, however I think this is overkill.

OpenID (as mentioned elsewhere) has problems and its uptake is declining. I rather think this is because it is trying to do far too much.

Gravatar on the other-hand is simple and to the point, requires the end user to do very little and is pretty damn simple to implement from a server point of view.

Could the same approach be used for profile fields? I think yes, and here’s how it might work…

  • First of all, we have a site somewhere which lets a user create an account and fill in their profile fields.
  • The profile comes pre-populated with common labels (name, description, location, interests etc), but lets users add extra fields if they like.
  • The service has a REST like API at the back end which accepts queries like: http://fooprofile.com/api/[field]/[md5 hash of email address]/ to which it returns a blob of text.
  • When a user creates a new account on bar.com, that site should attempt to pre-populate any profile fields with data from the service based on an md5 hash of their email address. These can of course be overridden locally.
  • Periodically bar.com should update its fields via the API, unless the user has overridden the profile field (or has otherwise selected not to do so).

Crucially with this light method, the user experience of the site remains pretty much unchanged and all the hard work is done magically in the background.

I also think that there is no need to specify what fields constitute a profile. The semantics of this will likely evolve naturally over time and there is no way to predict what extra fields will be needed. You wouldn’t dictate what tags someone would use, so why dictate profile fields?

In phase two of this you could easily imagine using OAuth to decide which fields a site has access to.

You could also imagine multiple providers being possible (providing the api was consistent). So when a user signs in to bar.com they are asked who there provider is – so they could select fooprofile.com or wibbleprofile.co.uk or any other provider. This would keep OpenID’s distributed nature, but without confusing the user too much – a url is always a url in this model.

So all that leaves is the single point authentication aspect as a distinct and separate problem, and one which must be solved in a way that is transparent to the user – perhaps an encrypted and public key authenticated token exchange using a similar technology as the above?

Just pondering….

Update: I have bashed together an example of the sort of thing I was talking about over here: http://skunk.marcus-povey.co.uk/aer/