These days, more often than not, when you attempt to sign up for a new web application or service you are asked to choose from a set of corporate logos one of which you presumably already have an account with.
These are corporate identity platforms which provide you identity and information access management as a free service. They are, generally, based on the second version of the OAuth authorization standard which allows a service to authenticate your possession of a third-party account (Google, Facebook, Twitter, etc) as well as request certain information about the account that you authorize. This creates an ideal solution for developers who may not feel comfortable developing an authentication mechanism or storing user credentials on their own platform securely. They can instead use one of the open source OAuth libraries as a plug-and-play alternative.
The OAuth security model can be thought of as a centralized system, (a) in the figure above, where the central node is the third-party account and each connected leaf node is an account on a service using a unique token to authenticate itself with the third party and request data. The only credentials a service stores are the token and associated account name for the third-party service. If these are compromised the attacker cannot gain control of the third-party account nor any of the other services with which the account is associated, but merely the information the token was initially authorized to access, as shown as (b) in the figure above.
While this model is relatively robust in many situations by providing a high level of service and information compartmentalization it does create a single point of failure. Since the root node, the third-party account, has to be trusted by all associated services it becomes a single point of failure. This means that if an attacker can compromise the third-party account directly, instead of targeting the leaf services, they implicitly gain control over all the associated services, as shown as (c) in the figure above.
The web security mantra often goes, in part, use a different password for every service. This makes sense. If an account for one service is compromised we don’t want to kick off a domino-like effect where the attacker now has access all our accounts. OAuth seems to swing both ways here. On one hand the token, essentially replacing a password, should never be the same across services and should change often, but on the other hand we are still using a single password to authenticate ourselves to a whole bunch of websites – it’s just happening via an intermediary. If this password can be brute forced or is carelessly reused for another less security conscious service and subsequently compromised the dominoes start falling.
However the real problem with this model doesn’t solely lie with lone attackers or with user password sanity but with state actors. No matter how secure Google or Facebooks OAuth or general authentication implementations are, they are still required to bow to court orders demanding access to your account and therefore all associated services. Or, less obviously, they might have their data centers covertly infiltrated by the more nefarious three letter government agencies, like the NSA, to siphon authentication tokens and credentials directly. Documents leaked by Edward Snowden have shown that not only do these agencies have the capability to massively collect data this way but are actively doing so.
So what’s the best solution? Well… that’s a hard question. There are a number of off-line encryption-based password stores which allow users to abide by the previously mentioned mantra. But these fail the mantra by requiring a master password to decrypt the stored passwords. There has been work on some clients that segment passwords into groups and use different passwords to decrypt each grouping, but this still fails the mantra, just to a lesser extent.
It all eventually boils down to usability. If it were up to security experts everyone would just memorize (or use pen and paper encryption schemes to store) the myriad passwords required to sign in to the ever increasing number of services we use every day, but this just won’t work. While a number of off-line encryption-based services are making leaps and bounds on secure cross platform based tools, large corporations like Google, Facebook, and Twitter who push the OAuth model have massive platform lock-in. This means that out of the big five or so providers there is a high probability that you already have an account with one, if not more. The lock-in allows these providers to create a high quality and extremely consistent user experience across various platforms which is near impossible to match by open source or independent developers.
Corporations pushing the OAuth model directly profit from the growth of their platforms by profiling user activity and as such are less inclined to discuss these issues with their users. In the end the user has to weigh the convenience of using a model with the hazards it presents in their decision. Unfortunately this decision is often weighted by lack of information and lack of high quality alternatives.