Requirements for a trustable cloud identity provider ("bring your own identity")

The reason we all have so many usernames and passwords is that there is no third party trustable federated identity provider. So each site manages its own identity system (occasionally trusting a few federated identity providers such as Facebook, Google, and Yahoo).

 Can you name a single trustable identity provider? We couldn't. That's why we started OneID.

A trustable identity provider means that the trust in the identity is due to the architecture of the system and not operational policy. So code changes at OneID can’t assert someone’s identity. Compare that to any other consumer identity provider were a simple code change could allow a person to assume someone else’s identity.

We made a list of 34 requirements for a trustable federated identity provider. OneID meets all the requirements below. Most other federated identity providers (such as Facebook or Google) meet just a few.

Facebook isn't safe or trustable. For example, Facebook says 600,000 facebook accounts are compromised each day.

Google isn't safe or trustable. When Stratfor was breached, the hackers used passwords there to break into thousands of accounts at Google and other sites.

Existing federated identity providers are all vulnerable to mass breaches, either at the identity provider itself, or any other large identity provider, can jeopardize accounts at other identity providers. In addition, any of today's federated Identity Providers (such as Facebook and Google) can make a simple code change and pose as anyone they assert identity for.

A trustable identity provider must do two important things:

  1. It must be trustable itself (relying on system architecture to ensure trust rather than policy)
  2. It must provide identities that can be trusted by relying parties (i.e., identity assertions that are end-to-end secure and that themselves are extremely difficult to breach at either end)

It is interesting to note that:

  1. With a traditional IdP, you can breach an identity at either end (user, IdP, or RP)
  2. With a OneID, you can breach an identity at neither end

Here's a list of 34 requirements that we think a trustable cloud identity provider needs to demonstrate:

  1. Identity can't be asserted without express consent of the user. This is the single most important requirement. It means that an identity system relying on a single assertion by a centralized identity provider fails this test because that service can be compromised which causes a mass compromise of all identities from that service. To meet this requirement, the identity protocols must require active involvement of at least one user device (and proof at the RP of 2 independent devices required for high assurance). Other than OneID, no consumer identity provider can meet this claim because all the IdPs use centralized assertions; you may authenticate using two factors to the IdP, but the IdP isn't trustable because it controls the assertion to the RP and the IdP can be compromised.

  2. No point of mass compromise (e.g., at the IdP or the RP)

  3. Externally auditable 24x7. Any code that touches your identity is always in plain sight, not behind a firewall (like every other identity provider you can think of). So the protocols themselves must be trustable, and they must be fully visible to the user (if he looks). There must be complete transparency.

  4. If malware is present inside the IdP that can read everything that the IdP sees and sends it out to an attacker, nothing bad can ever happen.

  5. No shared secrets (for example, there is no database at either OneID or any RP that, if compromised, would be useful). This applies to the proof to the RP of the user's identity, as well as proof to the IdP that the user knows the proper PIN or password. All of these must use asymmetric cryptography for proofs. In particular, even if the user doesn't have a smartphone, logins should never share secrets with the IdP (we designed a clever new patent-pending way to achieve this).

  6. End-to-end secure authentication and authorization so the assertion is re-hashed on each device signed by the user's device(s) and verified by the RP; there is no centralized IdP providing the identity assertion (which means public key crypto is required on the user's device).  Protocols that require centralized IdP such as SAML, OpenID, Oauth can't be used. PKI such as X.509 should not be used since both the CA's can be compromised and so can the private signing keys associated with the certificate (as Adobe found out when Adobe's signing key was compromised). This means that YubiKey and hard and soft tokens can't be used since they don't sign the transaction... they are vulnerable to MITM, MITB attacks.

  7. Support authentication, authorization, info sharing, and asserting and proving digital claims (such as "I am over 21").

  8. Minimum LoA can be elevated by user or RP to at least out-of-band 2-factor

  9. LoA levels must include both 2-factor in-band (i.e., single device) as well as 2-factor out-of-band (two devices)

  10. Privacy and security must be guaranteed by architecture (not operational policy). This includes keeping personally identifiable information secure (so it is not possible for OneID to decrypt and so it is never stored on any of the user's devices), using opaque, unidirectional  identifiers with RPs, and ensuring that OneID can't track what RP's you've visited and the RP's can't track where you have your identity stored.

  11. No Single Point of Compromise (SPOC) for any identity so attacking the cloud or a user device can't compromise an identity

  12. Easy to use; all the crypto must be hidden from the user so OneID appears to be as easy to use as Facebook

  13. Recovery must require high entropy secret stored at endpoints (never in a central location) combined with a second factor known only to the user (such as a PIN code). The architecture has to guarantee it is impossible for the OneID service to "reset" your password or email you a "reset" link.

  14. Available for desktop, mobile, and web applications

  15. Password optional. The identity shouldn't require the user to have to use a password (user's choice).

  16. Something you "know" (PIN and/or password) can't be offline grindable on the user's device or by the IdP. This requires that all uses of passwords and PINs  must be combined with a local salt and then used as a digital signing key.

  17. Consumer provisioned and managed identity so users could create it themselves, and "bring your own identity" (BYOI) to services that would trust it.

  18. The identity must be permanent. You should never be able to lose your identity or have it stolen in a way you cannot recover it and lock the attacker out. The public keys on file at each RP should never have to be changed no matter what happens. For example, if a device is lost or stolen, the user should be able to disable the device from any other device they have (or provision a new one). There would never be a need to go to individual RPs to notice them of a change since that would be unmanagable.

  19. Support all modern day browsers without requiring a download (so can be used on mobile browsers such as Safari on iPad and iPhone)

  20. Must support a user model of login to browser (or the mobile app if using with mobile apps) rather than individual websites or mobile apps so a user authenticates once to OneID once at the start of a session and can log off at the end (or use a timeout).

  21. Must support two classes of user devices with each maintaining unique private signature keys so that RPs can keep a permanent set of 2 or 3 public keys on file to authenticate a user (they keep 3 public keys on file if the RP requires high assurance). The minimum is two public keys: the primary device and the OneID repository. A third signature is used when the out-of-band device is used (the OneID Remote app). The two user device classes must share a symmetric key so that the primary device can communicate (via the OneID repository) the original transaction to the secondary device without the OneID repository knowing the contents of the transaction (so the OneID repository signature is always  a "blind" signature because it can never see the transaction; the repository signature indicates approval that the devices are authorized and the transaction LoA's have been satisfied, e.g., PIN code verified by the repository). 

  22. Transactions had to require at least two independent digital signatures (low assurance uses) and 3 signatures for high assurance

  23. Users would have their choice of which vendor hosts their identity and can easily move their identity to a different provider (of the identity) at any time

  24. Interoperable so that if you need to assert your identity to a relying party requiring SAML or OpenID or Shibboleth, that the identity system would accommodate that use (and without requiring extra authentications). 

  25. Users would be able to control the level of assurance (LoA) for signing into their devices and websites, and for approving transactions over a cumulative dollar amount (subject to being overridden by the relying party if the relying party requires an even higher LoA).

  26. User devices must obtain the secrets to the user's identity before being used through a one-time authorization process that securely (without ability for OneID to snoop the secrets) transfers the digital secrets from an authorized device to a new device. The OneID service is used to facilitate the transfer but in such a way that OneID can never learn the secrets of a user's identity. The OneID service alone cannot be used to authorize a new device; the user must bring a high entropy secret to the pairing process.

  27. Should work with devices a user already has.

  28. If a device is lost, the owner should be able to disable or remove it from his identity. Also, if there are sufficient consecutive authentication failures (such as 5 bad PIN or password entries), the device should disable itself from the identity without any explicit action from the user so that the device cannot be used with any relying party.

  29. Should never lock out a user from his identity (take a look at what happened when Facebook locked Chris Leydon out of his account).

  30. Should never remove two-factor requirements without proof. For example, Google violates this: if you add two-factor and complain, they will remove the two-factor requirements. Their focus is on user retention, not security. OneID is focused on secure identity.

  31. If a relying party needs an out-of-band two factor, there must be no way for the IdP to assert that. It must be proved with an additional digital signature.

  32. If malware compromises your machine, your identity shouldn't be jeopardized. For example, if an attacker gains access to one of your systems which was logged in, it should be possible to instantly disable that access. For example, with OneID, you simply disable the device. But if you used a username/password system and had your 1Password, LastPass, or RoboForm broken into, all of your accounts will have to manually be reset.

  33. Should not allow account reset based on email confirmation of the reset. OneID can't do this since it requires a high entropy secret that is never seen or stored at OneID. Most other identity systems allow this.

  34. You should be able to instantly disable any lost or stolen device so it can't be used to assert your identity anywhere. For example, if you are using usernames/passwords or SSO, you can't do this.

  35. The login credentials should never ever be phishable or keyloggable, even in the lowest assurance mode.

  36. There are cases when a user completely loses control of his an account to an attacker so there must be a way for the user to reclaim his identity without sharing any secrets with the IdP. For example, the IdP should be able to restore the identity on the IdP to a point earlier in time if the user has provided sufficient proof that he is the true owner of the account.

  37. The system must be immune to XSS attacks, e.g., by using static javascript and not allowing any code injection on the IdP site.

See also How Twitter could permanently end password breaches especially the comments at the end.

For more information, see OneID documentation