My life is miserable. They say password is hell, but you know what? Social login is just as shitty.
A couple of years ago, I understood it was time to step up my security by having stronger passwords. The way to do that is to have random complex ones that are different to each website. To deal with that, I am using a great small app called KeePass, which has its own Android counterpart. To keep them both in sync I use Google Drive (Dropbox in the past).
Then came Open ID. And went. It seems that everybody wanted to be an Open ID provider, but most sites ignored it and didn’t allow registration or logging in using Open ID.
This past year I’ve been adding less and less new accounts to my KeePass. Social networks are now the main means to register to a site – sometimes the only way. So there’s no more passwords and user names to remember – just apps that gather dust around our social network accounts.
Today I have 46 “apps” approved on my Facebook account, 17 on LinkedIn, 37 on Google and another 39. Some of I actually use, some are duplicates and others are ghosts. Though each platform provides ways to manage them and revoke their access, show me a person who actually uses that feature.
Up until now it wasn’t a problem – I somehow managed to deal with it. But it is getting harder each day. I wanted to comment on a GigaOm post. Since I haven’t done that in a while, the site didn’t remember me. This is the options it provided:
6 (!) different ways to sign in. Now, which one have I used in the past?
- Was it my long lost GigaOm Pro account?
- Maybe I used Facebook for this one
- Or was it Twitter? Not really sure…
- Might have been LinkedIn. I used it for “professional” settings
- Hell… why not use my WordPress one? I have that account somewhere
- Darn. Why not just submit it as a guest and be done with it?
And it isn’t just GigaOm – it is everyone these days.
Sure. For commenting there is no harm in it. but what about services like GetSatisfaction? Where your context matters in the long run. But – you get there from different other web sites that use it. Guess what? I found out I have multiple accounts there – from different social networks I can see different parts of my discussions there.
Identity hell.
I understand this all too well. I was very happy to see OpenID come on the scene, and it did gain some level of success. I actually implemented an OpenID Provider Server so any domain owner could operate his or her own OpenID server.
The big problem with OpenID is that the client-side code is complex. Some argued that the server-side code was hard, but I disagree. It took a day to write my server, and that was starting from scratch just reading the spec.
However, the client side was a problem. A client would have to accept a URI and then issue an HTTP GET on it. It should then look at the header and look for a Yadis reference. Finding one, grab that file and parse it looking for the OP endpoint URL. Failing to find a Yadis file, the client should parse the HTML document returned looking for tags lookin for the OP endpoint URL. Once all that was done, then the client could redirect the client and then (behind the scenes) communicate with the server so that the client can validate the response coming back from that browser redirection. The good news is that all of that complexity is already written in several languages. Even so, it is complex and when something does not work, it’s very hard to debug.
Some sites still support OpenID, but they are dwindling. However, the OpenID Foundation is not giving up. They’re creating an entirely new protocol to replace the old one. I’m not real happy about that, personally. Where is the complexity with OpenID? It’s all of the discovery stuff. If we tackled discovery, then OpenID is actually fairly simple.
What we started doing is defining a new protocol called WebFinger. That has a broad utility, but one use was intended to simplify the discovery process. Rather than trying to find the OP endpoint, the user (or the user’s OpenID Provider) could make that available via WebFinger. Simply query a user like https://packetizer.com/.well-known/host-meta.json?resource=acct:[email protected] and get a list of link relations. You’ll see my OpenID identifier there, but what you will not see is the link to the OP endpoint. To greatly simplify OpenID, all we would need to do is insert that one additional URL. OpenID client could would then be pretty simple.
The new OpenID protocol currently under development will use WebFinger, but it will also use OAuth. It’s moving away from its present authentication protocol. Perhaps if OpenID 2.0 did not already exist, this new OpenID (referred to as “OpenID Connect”) would be the perfect answer. However, it bothers me to some extent that the group is not focusing effort on solving the underlying problems, but rebuilding something entirely different. This will mean that have to sell the whole idea over again. Who will buy into it? I think it would have been an easier sell to advertise OpenID 3.0 as a simpification of OpenID 2.0. Use WebFinger, but get rid of Yadis and don’t require parsing HTML. The client/server authentication stuff is actually fairly simple and secure. Like I said, I wrote the server in a day. It’s not painful.
Just to add more confusion, there is also OneID and the W3C WebID. I’ve not looked at OneID much, but WebID looks interesting in that it uses browser-side certificates. I can see how that works well, until it’s time to replace a certificate and the remote server does not recognize your new one. I’m not sure how that’s handled. It also will not help you when you try to access content using another person’s computer.
Since the identity situation is an absolute mess, I just decided to use a simple hashing scheme. I created http://singlepass.packetizer.com/. I have a single password that I memorize and do not write down. For most web sites, I use a “service name” that is the domain name of the site I’m visiting. For my banks, I use the “pwgen” script to create a random 16-octet password that I use as the service name. That hashed with my password creates resulting strong password for the sites. Of course, I have to write down those 16-octet service names, but that’s only for stuff I want to be really secure. And, one cannot access my accounts without having both the service name (which I usually write down or is easily guessed) and may password (which I don’t write down and is impossible to guess).
It’s not a perfect solution, but it keeps me from having any single file sitting around that can reveal my passwords, I don’t have to remember lots of different passwords for most web sites I visit (since “one level” of password protection is enough), and I don’t have to rely on third-party software. What I wrote is trivial, but I published the source code for Linux, Windows desktop gadget, Chrome Extension, and the web page. They all implement the same logic. I’d like to have an Android program that does the same thing, but … one of these days. 🙂
Great post and excellent description of the issue faced by end-users. I totally agree that it is hard to remember what ID Provider you log in when you visit that site after a while.
We have over came this problem at LoginRadius by giving users option to retrieve forgotten login provider. It is pretty similar concept as ‘forgotten passwords/usernames’. Just enter your email ID and it will tell you what ID provider you logged in last time 🙂
You can check that out on our site and we are proud to offer this feature to all our customers!