When I wrote Enough with the Pain of Passwords someone told me it was completely self-serving. Actually, it was.

My day job is building a commercial Single Sign On product so I’m terribly biased toward people using it. I quite like my job, and I really like my product so I’m more than happy to get people to buy our stuff. This doesn’t actually change how I feel about passwords though.

I hate passwords. In current form they are an archaic mechanism for authentication and that mechanism is more often than not flawed.

Archaic is, I think, an appropriate word because we are fairly limited in how we can use passwords. This is because passwords are shared secrets. Both you and the application need to know the password – the secret. This makes it difficult to properly secure the secret because frankly, more than one entity knows the secret. However, shared secrets are a useful method for authenticating a principal because they are so simple to use, but they can be a challenge to use securely. Shared secrets tend to be static. They don’t change often because there often isn’t an easy way to change them.

Shared secrets create barriers between systems because each and every system in play needs to know the secret. Either you let everyone know the secret, or nobody new know the secret. The latter increases security (in theory) but reduces usability, while the former decreases security, and increases usability (in theory). When it comes to integrating such systems we don’t need yet another thing getting in the way. Sure we could argue that it’s more secure that way, but it’s not. It can’t be. If the business really needs these things to talk they will make them talk in ways that were never originally in the plans. That means security boundaries will likely be circumvented in ways the original developers never imagined. This can either be in a rich desktop client, or through a web browser.

This of course isn’t just true in a business – it applies to the internet as a whole. Users tend to consume data from one service and do something with it in another. If it’s a pain to move between those two services then the user is annoyed and that means they may just decide its not worth it – or worse they go the easy route and use the same password between the services so they don’t have to think. The less we make someone think about things other than what they are working on the better because they will do as much as possible to think as little as possible. As a user, I will do as much as possible to be able to think as little as possible when logging into things.

I might be mixing ideas here. In some cases the systems could be artificial like a server and applications, or it could be a person consuming content from one of the applications and trying to share it in another application. It could either occur through back channel API’s or through a user copying and pasting from browser tab to browser tab.

Imagine that you have an application, and to use the application you need an identity – in other words, its not anonymous. To get an identity you need to prove you are who you say you are. This is authentication. Normally we use passwords, and this means we have to manage passwords. We need a process to change them. To issue them. To reset them. To authenticate them. To store them. We tell our users to use something complex and secure. We tell them not to reuse it. We tell them not to write it down. All the while this is going to slow down the user because they aren’t going to remember the friggen thing anyway. Rinse, wash, and repeat for every application someone uses.

This does not scale. Either a user stops using new applications (or stops using older applications) or more likely the user just starts repeating their passwords. Let me repeat that, since very few developers seem to get this: passwords do not scale.

This is why we want federation. It’s not a new concept. Get someone else to do it. We have to be careful though. It’s not one size fits all – one single provider can’t be the sole source for identity information. Nor can we support every possible provider under the sun. That’s why last time I used the term persona. Business persona, personal persona, play persona, student persona, etc.

Imagine your target audience. Are you wanting to deal with businesses? Are you trying to do something useful for peoples personal lives? If you build in federation, they will use it. Maybe not immediately, but eventually there will be a critical mass of passwords and people will start transitioning to federated identities.

Does this solve our problem though? Is it secure? As all good answers are cop outs, it depends. The short answer is, it can be. It depends on how much we want to trust the identity provider, as well as how much we can trust the identity provider.

In other words, how much do we trust that the data we receive from the identity provider is accurate, and how much do we trust that it really is the person we want logging into the identity provider? For the first half its pretty simple: I trust the government to provide the SIN/SSN of the user accurately, but I don’t really trust Twitter to provide an accurate home address. Part of this is common sense. The other half revolves around how the identity provider authenticates its users.

We know passwords are weak so if the identity provider only allows passwords, maybe we don’t trust it to secure our intellectual property.  I trust Twitter to authenticate users for my new super-cool social media thingamajig, but I certainly wouldn’t trust it for my new business financial management solution. If the identity provider is using two-factor authentication then perhaps we can trust it a bit more. Does the identity provider allow for elevated contexts? Can we authenticate with passwords for generic access, but then request a stronger authentication method for certain things?

Now that’s an interesting thought. If you have an identity provider that can do this for you, you now have a new feature. Suppose your application is used in team scenarios. Multiple people accessing stuff might require management and administration. Anyone can read or create, but to modify or delete you need to elevate. Oops, heading off on a tangent.

Anyway, back on message: your authentication sucks and if I have to create another bloody password to use your new application, I’m not going to use your new application.

That might be a bit too harsh. Passwords can’t scale because I can’t remember anymore new passwords. If you require me to use a new password, I’m not going to remember it, so I can’t use your application.

This is a self-serving plea from me to developers: I hate passwords because I can’t remember them. Please make my life easier.