Authentication does not exist in a vacuum. It does not exist in a silo. The aim of authentication, is not authentication. It exists to support secondary events such as employee application access, consumer transaction completion or purchases. That seems pretty obvious when you write it down and read it aloud. However, we still tend to design identity and access management systems in isolation, using independent technologies, processes and workflows.
The main result of course is duplicated capabilities, complex journeys and fragility. This article is part of a series on authentication (see “Let’s Treat Authentication as a Life-cycle“, “Is Passwordless Still MFA?“, “What is Decoupled Authentication?” and “You’re Only as Strong as a Password Reset“) and I want to discuss what happens before and after the actual login event.
Let us start with a picture – they typically say a thousand words anyway. The above is a basic holistic, outlining a textbook approach to an authentication subsystem. Let us start with the central component – the authentication event. This will be characterised by the standard something you know, are and have. And generally a combination containing at least 2 of those. What has occurred in recent years, is the addition of “context”. This context refers to non-identity data, typically focused on threat intelligence, device and location data, previous transactions and behavioural characteristics based on peer analysis for example. We simply have more signals. More data inputs going into a main authentication engine. The result of that event was typically quite binary – “yes you’re authenticated” or “no you’re not”.
Most modern systems are slightly more grey, allowing concepts such as tagging, session properties and labelling to indicate varies different authentication output states and surrounding criteria. These are quite volatile attributes that can be added to id_tokens, sessions, cookies and so on to allow more fine grained decision making in the downstream relying systems.
What Happens Before Authentication?
What happens before authentication club, must stay in the before authentication club, club. OK maybe not. The before aspect was often handled by identity management systems as part of on-boarding, registration and proofing services. Essentially all the red box. The identity management system didn’t want to know it was “joe” – it wanted to know it was “Joseph Smith”, age, location and so on, all mapped back into varying attribute sources of differing levels of assurance. See NIST 800-63-3 for a bit of light reading on that topic. This has now evolved to overlay into the authentication enrolment process in order collapse the gap between the physical world and the digital representation – handled by the authentication sub-system. The bigger the gap between the physical and digital, the larger the opportunity for adversarial activity.
So the authentication event really only starts to become as strong as the “before authentication club”. Using a basic biometric such as FaceId for authentication, only really shows that the authentication context has not changed since the registration event. It doesn’t necessarily provide any assurance for downstream systems, unless of course you can tie that authentication event back to a physical identity with a level of assurance.
By tying the authentication event to an assured identity brings some interesting properties. The authentication event needs to somehow represent the physical world – and it would seem biometrics would be the simplest way to do this. You want to remove the opportunity for theft, phishing, spoofing and misuse. But that biometric event ideally needs be tied to a real identity – not just a silo’d biometric created in the authentication event space. The best way to achieve that is to start to correlate and overlay enrolment data with authentication data. The “before club” starts to become more porous alongside the authentication event. The biometric being used for login, is created during the enrolment phase and perhaps augmented with an assured source of identity data such as passport photo.
What Happens After Authentication?
We need to always think about what the authentication box in the middle is being used for. That helps us to left shift the design thinking and push requirements and capabilities back into the login process and in turn what data may be needed from both the identity enrolment and authentication enrolment events. A basic use case for authentication will be authorization – which will come in many different flavours in the form of native application access control, gateways and proxies. Essentially “OK, we know it’s Joe logging in and not just a generic user, and he can do x in system y”.
But more and more, authentication can power more complex and emerging use cases. In the consumer world what about the sharing of PII (personally identifiable information), the completion of consent requests for data sharing or the making of a purchase of completing a transaction. In the modern distributed workforce, concepts such as zero trust, contextual and adaptive access and remote working all require an assured authentication event to power the triggering of just in time access control.
Some other interesting properties emerge when we can start to remove authentication from being silo’d. One is regarding the recovery and migration of the mechanics needed to power authentication. In the world of things like challenge response style login with private keys and crypto (yes, crypto as in cryptography folks, not digital currencies) if the credential is lost or compromised, we need to go through an authentication re-enrolment ceremony. That is open to compromise if again the gap between that event and the physical identity is too large. By having it tied more closely to an assured identity, the re-enrolment becomes essentially more seamless requiring less intervention and less re-validation. Keys can be derived or retrieved from distributed systems based on an assured biometric identity check.
Does My Phone Do This Already?
But doesn’t my phone do this already? I login into my iPhone or Google Pixel with a fingerprint. You do. And you may well use that fingerprint to say complete an NFC based transaction at a “wave and pay” point of sale terminal when buying your coffee. You uploaded your credit card details into your mobile, securely storing the card data (or more likely a tokenized copy of the data) into the secure element on the device. The access steps to the process to release that data is protected by an OS native authentication event, driven by local biometrics. The owner of the biometric and owner of the card may not be the same person. They are not linked. The biometry processing perhaps doesn’t even leave the device. That isn’t to bash native OS biometrics – they are a hugely successful method of protecting a complex and highly value computer in my pocket, that provide a good combination of security and usability. But again the authentication is really silo’d in that design. It is not that closely tied to the physically assured identity and not really linked to the downstream event.
As identity is becoming the foundation for many critical and emerging design patterns for consumers and employees, the authentication event processing block, really needs to become more porous – allowing data to flow in and out – to provide both a higher level of assurance and greater opportunity for downstream system integration.
About the Author
Simon Moffatt is Founder & Analyst at The Cyber Hut. He is a published author with over 20 years experience within the cyber and identity and access management sectors. His most recent book, “Consumer Identity & Access Management: Design Fundamentals”, is available on Amazon. He is a CISSP, CCSP, CEH and CISA. He is also a part-time postgraduate on the GCHQ certified MSc. Information Security at Royal Holloway University, UK. His 2021 research diary focuses upon “How To Kill The Password”, “Next Generation Authorization Technology” and “How IAM Countermeasures Can Defend Against Cyberwar”. For further information see here.
Other authentication articles by the same author:
Let’s Treat Authentication as a Life-cycle