A Web App Store That Makes The Web Safer24th Oct '14 • 9 of your Earth minutes
Maintaining security & privacy without the loss of convenience
TL;DR*: Using ‘Login with Facebook’ et al to sign up for new services has too much of a social ‘cost’ which is one reason why we still opt for creating new accounts with the same old passwords. So I present a solution that could solve this problem and at the same time showing the potential to introduce a kind of ‘app store’ for the web.*
Edit December 2018*: I’ve been reminded of this article in the wake of this year’s Facebook scandals, especially its most recent this week. As far as password security goes, I now use 1Password as an interim solution, and there are a number of very interesting developments in security on the horizon which in many ways resonate with my ultimate conclusions in this article: no passwords* and no social sign-in feels like the best way forward.
There’s been an increasing number of high-profile password leaks in the past few years. And with 2014's own shocking security revelations with SSL (Heartbleed and POODLE) and bash (Shellshock), it looks like more woes for worried webizens — and more headline-grabbing phrases to come.
Yep this is the problem!
So when I hear of attempts to fight this intangible threat, I am always intrigued to see what today’s solution will be.
There have been many options put forward:
- Educating users to use stronger passwords, to change passwords regularly, to use different passwords for different services.
- Educating developers on password-handling best practices such as secure hashing, salting.
- Introduction of new technologies such as 2-factor authentication (Security Key) and passwordless entry (or one-time passwords/single-use tokens).
These are all wonderful options and in combination they are extremely effective at fighting account hijacking through guessed/stolen passwords.
The Price of Security
All of these attempts at solving the problem add burden to each party — the price of security.
Users may have to create countless, long and hard-to-recall passwords which they should renew regularly (yawn). This pain point means many don’t follow the guidelines and end up creating and using the same weak passwords everywhere and never changing them… ever.
For developers it means swotting up on the latest preventative technologies and implementing and maintaining them in case flaws are found.
We’re all constantly repeating the same bloody tasks! What the hell are we doing people?? There has to be a better way!
Enter OpenID & OAuth
OpenID and OAuth have been around for a while now. Maybe you’ve used them? Ever done a ‘Login with Twitter’? That’s OAuth.
(You can skip this part if you know how OpenID and OAuth work and what they’re meant for)
OpenID and OAuth share the same basic goal: allow third-party applications to communicate with each other without users having to give either of them their actual passwords. OpenID allows users to register with authentication services that would then authorise the user on request by a third party application. You can still use this on some sites such as StackOverflow.
StackOverflow still allows users to login with OpenIDOAuth is similar, but its main goal was as an extension to OpenID. OAuth providers are specifically soliciting connections from/to third party apps on behalf of an authenticated user. It’s essentially a way for apps to provision API keys with other apps at the user’s will, without the burden being placed on the user whilst also giving them more fine-grained control.
Before OAuth, getting two apps to talk to each other usually meant manually handling an API key from one to the other. There was very little control over what was possible for people in possession of the key and very little you could do if it got lost or stolen. Perhaps you could regenerate your key, but then you would have to update all of your valid integrations to use the new key.
With OAuth, as a user using App A, I could tell it to go to App B with the specific intent to get an API key, for itself. After authenticating with App B, I would be redirected to App A, giving it the go-ahead to generate and use its own key that won’t work with any other app. It’s own key that I can turn off from within App B without affecting any other integrations.
It’s clear that App B is now authenticating this user for App A — if the user has authorised the link between the two, App A can simply check with App B to see if the user is logged in on App B and essentially use that as proof that the individual at the terminal is the same user.
OAuth complemented OpenID for a time (and in many ways is borne out of the ideas of OpenID), but as of version 2 (more formerly known as OpenID Connect), the two have essentially fused together to become the ultimate passwordless authentication mechanism. And they are mostly secure.
More and more libraries are available for more languages and platforms making the setup and management of an OAuth server and client (almost) a breeze.
Due to the high adoption rates of Facebook and Twitter (among others), it’s becoming increasingly popular for developers to set up a ‘Login with Facebook’ or similar whenever you’re registering for a new service.
Indeed, promoting this particular use-case is beneficial to both the OAuth provider (e.g. Facebook) and the app that consumes the user’s acceptance (App A), hence why Facebook and Twitter have pushed this so hard over the past few years.
For example, if I sign up for a new service with my Facebook details, that service may ask for various details available from my social profile — my friends list, my email address etc — and permission to carry out certain actions on my behalf — liking pages, adding new friends, posting to my timeline etc.
Facebook also benefits in this scenario. Suddenly they know a little more about me — they know I use this app… and they know I’m prepared to give away some of my powers and privacy.
Edit: I’ve just watched Aral Balkan’s fantastic talk about privacy, Free is a Lie, and have been finding out more about his recent venture, Ind.ie. It has given me even more impetus to make something that is secure and doesn’t ‘default to public’.
Now for some apps this is obviously a desirable (even critical) part of their functionality and as a user it might be a clear case for me to see why I should be ok to give them that sort of access. Fair enough.
However, if it’s less clear and it seems like they’re just using the social login as a way to gain a foothold into my network/profile/life, I’m more inclined to sign up using more traditional means, if those are available, or not at all. In most cases that means email address/username and (same old) password.
To be brutally honest… for me that means reusing the same format of password I’ve been using for a while. Why? Convenience for one. But I’ve weighed up the possible outcomes: either I give this app access to my social network account and it does something I didn’t want it to in front of people I didn’t want it to, or I give it a password similar to my usual passwords (and risk this being stored in plain text on some half-secured hard drive somewhere.)
As a user, I’m having to weigh up two unknown costs — both potentially damaging to my online persona either now or at some indeterminate point in the future, whether or not I continue to actively use this app.
¡No me gusta!
So why can’t we have an app that just allows ‘social sign-in’ except without the social?
This does exist in a form, but adoption rates are extremely low when compared to the Twitter and Facebook sign in options, likely because of the high brand awareness and confidence.
However as time goes by, more and more users will want to break free from the unknown consequences of social sign-in. So what do we do?
Simple: we build an app that acts as an OAuth 2 server, but has no social features whatsoever. It simply allows consumers to gain access to basic details of the user (name, email address) all openly acknowledged and explicitly and granularly allowed by the user.
Benefits to users:
- No more sign up forms
- No more fear of social sign-in fallout
- One login for every app
- Never give out another password
- Single place to change password/set up 2-factor auth
- Possibly also keep the user’s email address hidden, adding an extra layer of privacy
- Total control and insight into the apps they use
- Possibly loads more (multiple identities under one account, quick access to apps from a central dashboard)
What about for developers?
- No need to recreate traditional sign-up and authentication processes
- We could even provide client libraries for each language that do everything they need out of the box
- Easily extend into existing apps
How would we fund such a thing? Some ideas include charging app developers a minimal amount for handling signups and logins on their behalf. Off the top of my head, $10/month for 10,000 sign ups/logins, with sliding scales around that…
Why would they pay?
Well, firstly this is pay to play. But surely ‘playing’ is just giving users all those benefits and not having to worry about handling auth? Pfft, big deal. That’s no fun.
Edit: I guess a slightly more compelling reason is no advertising/marketing of customer data — you are not the product!
Right, that’s lame and boring. But what if playing also meant you were listed in the only serious web app store going? And what if that web app store was eventually able to include some of the following features?
- Easier discovery of your app by potential users
- Frictionless 1-click, sign up to your app with a centralised payment system
- Ability for your app to discover what other apps your users are using and eventually ask your users for access to their account on other apps so that you can cross-communicate and do cool stuff for them!
That could be a fun playground to be in! There is a lot of potential here for what a basic authentication platform could become and how it could help web app developers bring in lots of new users. All the while saving people’s (online) lives, one corner of the web at a time.
Potential Stumbling Blocks
The biggest stumbling block is ownership of data. Many companies developing apps like to have access to all of a user’s data for themselves — in many cases this is a legal requirement. There are pros and cons to that. I think it’s still possible, but my focus is on what’s right for the user.
And what happens in case a user forgets their login details to our auth app? Well we’ll still use the (secure) traditional methods of recovery.
And adoption is always a tricky one. Yes we’ll be competing against the likes of ‘Login with Twitter.’ It’s chicken and egg… users won’t adopt if there are no apps that authenticate this way. And devs won’t adopt if there’s no appreciable benefit.
Edit: Someone suggested the possibility of even paying developers to adopt. Done right, this could definitely be a way into a certain level of adoption.
What about the worry of this being a single gatekeeper? Well I haven’t said it couldn’t be federated… We don’t seem to have too much of a problem with Facebook and Twitter being gatekeepers of our identities and look what they do with it… pimp us out to the highest bidder.
Twitter and Facebook sign-in are only possible because of the popularity of the apps. Without that they simply wouldn’t exist. But I don’t believe this idea needs to be any more compelling. People don’t want a pointless app. This is a real need and I’m sure when users and developers see the benefits they will go for it.
I envisage this app becoming (yet) another authentication option. But for discerning users that don’t want the fear of social sign-in collateral damage, it could be a better option than signing in with Twitter and Facebook. With no social feed for apps to tamper with, that barrier is removed. And it could be lighter and less uncertain than newer technologies that rely, for example, on browser enhancements.
For users who don’t have an account on the right social network, this could be even more enticing: no need to create yet another account on yet another service, keep using the one specifically made for purpose.
The ultimate goal will be to simplify authentication, for it to become something that actually helps developers and users get on with far more interesting challenges whilst maintaining and hopefully increasing the relative state of users’ security.
I’m going to begin development on my own, because I can. But if you think this is a good idea and you’d like to part of it, get in touch with me via Twitter — @simonhamp — let’s build a beautiful future together!