Welcome again to the third installment in my Passwords series. So far we've learned about
how passwords get hacked and how you can
keep yourself safe in this broken password world. I have good news though, while things are broken and blatantly insecure now, there's hope for a secure future. A lot of the world is probably going to disagree with me, but I see a future with passwords being almost completely wiped out, and being replaced by social sign on. You've all seen social sign on somewhere - "Log In with Facebook", "Connect with Twitter", or less often,
OpenID. It hasn't picked up steam yet, but social sign on gives web sites the ability to authenticate users without requiring them to register with a username and password. I've mentioned the holy grail of security in the past, and I think this may be it.
The idea with social sign on is that you're already registered with Facebook (or twitter, or openID, or many other potential services), so new web services can piggyback Facebook's authentication system to sign you in to their own system. Within Facebook there is an apps section that gives you the ability to allow or deny certain apps the ability to ask Facebook for your authentication. This is a beautiful thing, because instead of relying on the vast multitude of developer's in the world to correctly understand security, we can instead rely on a well-known platform with defined security standards to store your single password.
The downside here, as I mentioned, is that this system hasn't picked up traction yet within the developer community. As much as I get worked up about this, there's actually good reason that it hasn't gotten traction. There's two main platforms out there right now that provide social sign on - Twitter and Facebook. The good news is that 90% (100% guesstimate) of the internet community is registered at either Twitter, Facebook, or both, so 90% of the internet community can access sites that use social sign on. However, when an app uses social sign on to authenticate, they're required to fit into different "permissions buckets". For instance, MyAwesomeService is going to use Twitter's social sign on, but to do so they have to fall into the "read" permission bucket for Twitter. Users, when they try to connect to MyAwesomeService via Twitter, will be shown a dialog asking if they give MyAwesomeService to read their tweets, list their friends, etc.
Users don't like this. Rightfully so, I don't want every application in the world to be able to read all my tweets!
The solution here - and I condemn Facebook and Twitter for not providing this functionality already - is to have a permissions bucket that doesn't require any access, aside from authenticating the user. We see this sort of thing with systems like
OpenID. In fact, OpenID doesn't actually have any functionality other than authenticating you, it's just not used because no one has an OpenID account.
Now that you're all professionals on the mechanics and practices of passwords, I would like to propose a challenge to fix the problem. If you're a developer, go right now to your boss, to your ticketing system, or even better just straight to your IDE, and begin the process of implementing social sign on. I don't care if it's Twitter, Facebook, OpenID, or some other system. Regardless of the direction, it's our responsibility as developers to understand security better than our users, and to guide them into better practices - it's not about how many new users you get, it's about treating those users like you care about the data they're sharing with you. If you're not a developer (or, if you are, and also use the internet)
stop using passwords. Granted, some services are behind the curve, and you will just need to
use a strong password policy, but if you see the option for social sign on,
use it. You owe it to your own security, but you also owe it to the rest of the internet community to support the trend of password
abstinence safety.