Association is the New Authentication

The efforts to increase security and eliminate fraud via stronger, more obtuse and higher friction user-based authentication has not left us more secure - it has just irritated the user. The solution is out there, and that solution is association.

The focus for user security for the last 20 years has been to come up with new forms of:

  • Knowledge: Something user knows (password)
  • Possession: Something user has (tokens)
  • Inherence: Something user is (biometrics) 

There are big problems with this approach - namely, every new service needs to start from scratch as if this user has never been online before. That is to say, the B2C (Business-to-consumer) application attempts to create a new identity, with as little as just an OAUTH (federated token) for trust.

This process of creating new identities for every app is expensive for the enterprise and a time consuming deterrent for the users, and we haven’t even started on the authentication flaws. Your standard authentication is susceptible to the credentials (passwords, tokens, biometrics) being stolen or replayed.

The last flaw of the standard authentication story - which is the most unacceptable flaw in a world as interconnected as we are today - is that the authentication process itself is “static”.

That is, the authentication is a binary yes/no (usually based on static information the enterprise holds), which leaves NO room for confirmation and status of the identity (stolen, misused – who knows?). Lastly, there is no room for an analogue system of trust of the authentication... are we 100% sure of the user, or just 75% or 30%? (Shouldn’t we adjust the information/resources offered to this user if we are only 50% confident that this is the user?)

The Solution is: Community Authentication

A key “truism” of modern identity is this: the IDENTITY already exists, it just a matter of:

  • Choosing which IDENTITY to trust
  • Establishing a new trust
  • Determining a LEVEL of trust based on current information available
  • Feeding (back to) the global trust model

Examples of the new trust model:

  • Keybase.io (Utilizing social media to associate encryption keys - https://keybase.io/
  • SecureKey Concierge (Leveraging Existing Trusted IDs for Gov’t Accounts)
  • Civic.com (Blockchain identity weighting system) - https://www.civic.com/
  • ID2020 (Microsoft/UN’s global ID system)

Keybase.io

Keybase is a new and free security app for mobile phones and computers. It is a very compelling user-friendly tool that enables users to create and utilize encryption keys in common communication (email, messaging, etc.).

The solution does NOT offer any new technology. It supports PGP and GPG encryption keys. The novelty is the ease of use of associating an existing social identity with a powerful security mechanism: Private and Public Keys.

It allows you to not associate your own IDENTITY to the encryption system – but also see the association of others on the network:

Image 1: Keybase allows me to see the associates that user “azaslawski” has associated to his keys – to help me decide the trust level

The major “coolness” of the keybase.io system is the association of the security keys with an existing Identity. In addition, allowing the sender to make up his own mind on his trust level of the user – based on the “associations” this user has with more than one social account.

Yes – it’s a manual process of trust – but keybase.io is a great exercise to help one start to understand how social trust should and could be established.

SecureKey Concierge

SecureKey Concierge is an interesting look at the B2C identity problem. The first problem they solved was how to provide trusted (not standard OAUTH/Facebook) identities to a secure resource. Their first target apps were the Canadian government resources (Federal and Provincial).

The government had previously made users create their own accounts and go through a painful affirmation process (Canadian Post and other cumbersome methods). In addition, as these government accounts were often only used once a year – during tax time – the number of password reset and locked accounts was substantial.

SecureKey Concierge came up with a unique approach: why not have the government sites trust accounts that the already have substantial security and trust built-in and are used almost daily by the users? Namely, the user’s online bank account.

So SecureKey Concierge created a partnership with 11 Canadian financial institutions, including RBC, CBC Scotiabank and others. In additional they created a system that allowed the government accounts to accept a logon from these accounts.

This was a big win for all involved:

  • For the governments involved, this meant 7,000,000 users already created and ready to trust
  • For users, they had one less online identity to manage
  • And for the banks, they had increased customer attachment and utilization

The program did not go unnoticed in the identity world. IBM has formed a partnership with SecureKey to create a greater B2C financial trust system leveraging IBM’s esteemed Hyperledger Blockchain system. The effort hopes to create a decentralized system of trust that goes way beyond just bank users and Canadian government entities.

Civic

The last one I’ll go in depth on is the Civic blockchain solution. Civic is a very novel approach to identity and the storage, dispersal and trust of identity information.

Civic enables the user, via a mobile app, to store their personal identity information (PII) on a mobile device. Enterprise can request the information via a request to the Civic system. The user receives the request for PII/PHI (protected health information) and then decides to issue the enterprise the data.

Pretty neat system – but wait, there’s more!

The enterprise knows it can trust this user’s information because of the blockchain-based trust score. That is, a healthcare provider knows it can trust the PHI from the user, because this user’s car insurance company also trusts this link for data, as does the person’s cellphone provider, as does the county, state and country they live in.

The data is trusted - not because the user says, “trust me” – but because of the AGGREGATE of trust from other providers stored in the blockchain by Civic.

Summary

I’ve been working in authentication and SSO for over 20 years. It’s obvious to me that siloed (one resource) identities authenticated by static (some legacy 2-factor) systems are simply not enough. More is needed – for B2C solutions, trust and affirmation of the user’s identity outside the system is a must.

For enterprise B2E users, well – that’s a whole ‘nother blog…