Nearly all the big player social networks now provide a multi-factor authentication option – either an SMS sent code or perhaps key derived one-time password, accessible via a mobile app. Examples include Google’s Authenticator, Facebook’s options for MFA (including their Code Generator, built into their mobile app) or LinkedIn’s two-step verification. There are lots more examples, but the main component is using the user’s mobile phone as an out of band authenticator channel.
Phone as a Secondary Device – “Phone-as-a-Token”
The common term for this is “phone-as-a-token”. Depending on the statistics, basic mobile phones are now so ubiquitous that the ability to leverage at least SMS delivered one one-time-passwords (OTP) for users who do not have either data plans or smart phones is common. This is an initial step in moving away from the traditional user name and password based login. However, since the National Institute of Standards and Technology (NIST) released their view that SMS based OTP delivery is deemed insecure, there has been constant innovations around how best to integrate phone-based out of band authentication. Push notifications are one and local or native biometry is another, often coupled with FIDO (Fast Identity Online) for secure application integration.
EMM and Device Authentication
But using a phone as an out of band authentication device, often overlooks the credibility and assurance of the device itself. If push based notification apps are used, whilst the security and integrity of those apps can be guaranteed to a certain degree, the device the app is installed upon can not necessarily be attested to the same levels. What about environments where BYOD (Bring Your Own Device) is used? What about the potential for either jail broken operating systems or low assurance or worse still malware based apps running parallel to the push authentication app? Does that impact credibility and assurance? Could that result in the app being compromised in some way?
In the internal identity space, Enterprise Mobility Management (EMM) software often comes to the rescue here – perhaps issuing and distributing certs of key pairs to devices in order to perform device validation, before accepting the out band verification step. This can often be coupled with app assurance checks and OS baseline versioning. However this is often time-consuming and complex and isn’t always possible in the consumer or digital identity space.
Multi-band to Single-band Login
Whilst you can achieve both a user authentication, device authentication and out of band authentication nirvana, let’s spin forward and simulate a world where the majority of interactions are solely via a mobile device. So we no longer have an “out of band” authentication vehicle. The main application login occurs on the mobile. So what does that really mean? Well we lose the secondary binding. But if the initial application authentication leverages the mechanics of the original out of band (aka local biometry, crypto/FIDO integration) is there anything to worry about? Well the initial device to user binding is still an avenue that requires further investigation. I guess by removing an out of band process, we are reducing the number of signals or factors. Also, unless a biometric local authentication process is used, the risk of credential theft increases substantially.
Leave your phone on the train, with a basic local PIN based authentication that allows access to refresh_tokens or private keys and we’re back to the “keys to the castle” scenario.
User, Device & Contextual Analysis
So we’re back to a situation where we need to augment what is in fact a single factor login journey.
The physical identity is bound to a digital device. How can we have a continuous level of assurance for the user to app interaction? We need to add additional signals – commonly known as context.
This “context” could well include environmental data such as geo-location, time, network addressing or more behavioural such as movement or gait analysis or app usage patterns. The main driver being a movement away from the big bang login event, where assurance is very high, with a long slow tail drop off as time goes by. This correlates to the adage of short lived sessions or access_tokens – mainly as assurance can not be guaranteed as time from authentication event increases.
This “context” is then used to attempt lots of smaller micro-authentication events – perhaps checking at every use of an access_token or when a session is presented to an access control event.
So once a mobile user has “logged in” to the app, in the background there is a lot more activity looking for changes regarding to context (either environmental or behavioural). No more out of band, just a lot of micro-steps.
As authentication becomes more transparent or passive, the real effort then moves to physical to digital binding or user proofing…
Comments are closed