To access an online account you need to sign in. Traditionally, this requires you to enter a username and password. Typically, these are different for each service you have access to. In a business context, it makes sense to centralise the management of both user accounts and the services they are authorised to access. This has given rise to a form of federated identity management, where users sign in to one single central identity provider. This identity provider usually also manages the user authorisation and seamlessly logs the user in to the desired service. The advantages are obvious: the user only needs to remember a single username and password, and the business manages service authorisations in a single place.
Unfortunately, this federated model of identity management is used more in more in a consumer setting as well. Examples are services like Facebook Connect which: "makes it easier for you to take your online identity with you all over the Web, share what you do online with your friends and stay updated on what they're doing. You won't have to create separate accounts for every website, just use your Facebook login wherever Connect is available". This is an incredibly bad idea.
It is like you are living in a large apartment building and instead of having a key to your house, the janitor owns the keys to all apartments in the building instead. To enter your house, you ask the janitor to open the door for you. It's even worse: the janitor also holds a key to your safe, your car, etc.… In real life we wouldn't ever trust a janitor and endow him with this much power. He might be bribed, or simple forced to cooperate... Then why do we trust Facebook with similar powers in the online world? Especially if we know that intelligence services like the NSA can request all your Facebook account data (possibly including authorisations for other services)?
And it's not only Facebook. Schemes like OpenID, SAML, even certification authorities (like Verisign) in a public key infrastructure (PKI) have similar powers.
A strong authentication mechanism relies on public key cryptography. A user creates a key pair, and gives the public key to the service provider when signing up for an account. To access the account, the user needs to prove it owns the corresponding private key using a challenge response protocol. To prevent the need to maintain a large database of public keys for user accounts locally, the service provider could decide to use a certification authority (CA) to issue certificates that bind a public key to a user account instead. Then users receive a certificate for their public keys, and the service provider only needs to store the public key of the CA to verify all certificates it receives. However, this gives the CA the power to access any account, simply by generating a key pair and issue a certificate that binds the key to the desired account. In other words, it becomes as powerful as the janitor in the apartment building. In fact, any PKI delegates control from the leaves of the hierarchy, accumulating power up to the root.
In real life, we have different keys to open the front door of our house, open our safe or start our car. We may have a spare key, and a locksmith who knows the serial number of the key (or the lock) may be able to produce a new one. But never would a locksmith be able to create a new key that magically fits on our lock (excluding the possibility of master keys for the sake of argument) without such information. Using separate keys spreads the risk.
Again I wonder: why do we accept such a drastic change in trust assumptions in the virtual world?
Any authentication mechanism that does not require the service provider to store something specific for each user account runs the same risk. Trusting the janitor is but one example of the current Identity Crisis.
Maak ik hier uit op dat voorzieningen als Qiy / Doors niet zo’n goed idee zijn? Als je Doors gebruikt kan je altijd nog direct inloggen op alles, dus buiten Doors om. Maar inderdaad, je geeft aan Qiy / Doors de beschikking over je inlognaam + wachtwoord. Zou het denkbaar zijn om wel de voordelen van zo’n systeem te hebben: wachtwoordbeheer en verificatie dmv een sms-code, zonder de nadelen: je moet Qiy maar vertrouwen op hun blauwe ogen?
[…] a previous blog post I wrote about the risks associated with federated identity management. In such systems users do not […]
[…] op de veiligheid van dergelijke systemen is overigens wel een en ander af te dingen. De kern van het probleem is dat een groot aantal partijen vertrouwd moet worden voor […]
That’s not how reusable identities are supposed to work in the consumer case. If implemented properly the relying party offers to the end-user: 1. Choice: between what identity providers to connect to an existing account: Google, Facebook, a provider operated by the relying party (i.e. traditional authentication), a personal OpenID provider that the user runs) 2. Control: some sort of self service console in which the user can disconnect an external identity provider at any time (after signing in, yes)
So if you don’t trust that identity provider, don’t connect it to your account. If you no longer trust an identity provider that you once trusted, connect one that you do trust, and disconnect the untrusted identity provider from your account.
Now in practice, relying parties may chose to only accept Facebook as identity provider. That would be bad. Maybe they’re too lazy to implement support for alternatives (if that’s your problem, then you should support work on standardization of OpenID Connect, SAML, AccountChooser, … so as to make it as easy as possible to support external identity providers). Or maybe the relying party only trusts Facebook (that’s their choice, you vote with your feet).
Giving user choice about which identity provider is responsible for authentication doesn’t mean there should only be one single central identity provider (with NSA back doors and all).
I don’t know how to formulate this in terms of your metaphor (users bring their own lock (service), which the janitor installs for them, and they can ask the janitor to replace the lock at any time).
Anyway, the alternative is worse: users tend to re-use passwords, relying parties get hacked. The real problem, IMO, is that remote authentication of end-users (including security, account reset, multi-factor, …) is hard and expensive and, where possible, it makes sense to externalize it, not only in enterprise situations (in which centralized authorization hardly a reality, BTW) but also for consumers out on the open Internet.
I don’t see your point. What you are describing is exactly the janitor scenario: yes, you can decide to give the janitor the key, and you can decide to take the key from him. But, like you said, some apartment buildings force you to give the key to the janitor…
Any of the alternatives you mention have the same problem: I have to trust OpenID Connect, SAML, AccountChooser or whatever to not violate my security for services that they themselves do not offer. There is a difference between just trusting a bank, and trusting OpenID Connect not to rob me blind because I can only access my bank account through them. In the physical world we are sensitive to such subtle trust issues. In the virtual world we are (apparently) not. And this surprises me.
I agree, the alternative is not to have username and password at every service provider separately. I was more thinking along the lines of using public key based authentication along the lines of SSH (Secure Shell, that does not rely on certificates) combined with mobile devices. But this is actually ongoing research about which I hope to be able to report about here soon.