Passwordless authentication is often described as improving both the usability and security aspects of both the employee and customer identity journeys. Many approaches to passwordless have emerged over the last 5 years – including hardware, software, biometric and standards based initiatives.
In November 2021, The Cyber Hut released a 61 page buyer guide for passwordless authentication, describing the vendor capabilities, requirements, integration options, B2E and B2C use cases and planning recommendations for migration.
A brief snapshot of questions to consider, when engaging software based solution providers in this space is described here.
1 – Are standards such as WebAuthn / FIDO2 supported?
The discussion around whether to leverage open standards or proprietary approaches has long existed – and applies to many different technology areas. From a security and identity perspective, many standards exist – from the likes of LDAP, OAuth2, OpenID Connect, SCIM, FIDO and more latterly WebAuthn and FIDO2. The reliance on open standards can provide many benefits – either via the open and collaborative way the standard develops (many eyes, removal of errors, reduced likelihood of back doors etc) through to improvements for interoperability.
In the passwordless specific domain, the rise of the W3 supported WebAuthn has emerged as the dominant approach for a cryptographic based approach to authentication. The standard (from April 2021) is essentially a challenge response based protocol that uses asymmetric key cryptography. Two keys are generated on a per device / website interaction – one private, one public. The private key is kept secure and is leveraged during a challenge from the website that the end user wishes to authenticate against. The public key – that is mathematically linked to the private one – is used during the verification process. There are some interesting properties in this approach. Firstly no shared secrets are needed. Secondly each key pair is tied to both the device and the relying party (or website) that wishes to perform identity verification. This helps reduce the blast radius if a private key was in the unlikely event compromised – only the associated relying party would be impacted. A couple of good web resources to explain this process are the WebAuthn.io site by Duo Labs and the WebAuthn.guide by Duo Security.
Why is this an important question to ask? Many passwordless based approaches rely on asymmetric cryptography. Whilst a proprietary approach does not intimate a lack of security, understanding whether a standards based approach was considered can show vendor maturity, age and how their roadmap for interoperability may develop.
2 – If an app is used where are cryptographic keys stored?
A common model for passwordless authentication, is to use the mobile phone as a possession factor – managed quite typically by a mobile app. The app can be generic and available from the Apple or Google stores, or custom to the client deployment. Either way, the end user will leverage the application to engage in some sort of interaction with a cloud service that will provide authentication response services to the requesting website or relying party. As described above, this will likely use asymmetric cryptography – either in the form of WebAuthn or a proprietary method. An important topic to consider, is where the private key in these transactions is stored. The WebAuth spec for example describes compliant authenticators “…executing (a) on a general-purpose computing device, (b) on an on-device Secure Execution Environment, Trusted Platform Module (TPM), or a Secure Element (SE), or (c) off device. Authenticators being implemented on device are called platform authenticators. Authenticators being implemented off device (roaming authenticators) can be accessed over a transport such as Universal Serial Bus (USB), Bluetooth Low Energy (BLE), or Near Field Communications (NFC)“. In the case of an app based approach, we would assume the use of a TPM or SE. The general purpose aspect could assume the use of things like a trusted execution environment – so not a dedicated location, but still isolated from general application usage – see for example the Trusty the TEE by Android.
Why this is important to ask? Well it clearly is a huge security concern. Access to the private key by an adversary is essentially back to the “stealing passwords” level of vulnerability. The key needs to be protected from theft, tampering, misuse, copying and extraction. Having it stored in an accessible location in memory or disk is not a good place to be.
3 – Can enrolment and login leverage an app-less / QR code based process?
Whilst an app-based approach to MFA is common, there maybe scenarios where the management and deployment of an application may be cumbersome, or not possible. This is likely more prevalent in the consumer, customer or citizen based identity and access management areas (see here my book on the more detailed CIAM design components). What does this mean? Well during the enrolment and login flows, an end user may not have the authn application installed. Should that preclude them from using a service, or completing a transaction? In the CIAM world that would be seen as a pretty big barrier and likely result in an abandoned shopping cart scenario. A novel approach to this, which has emerged during the Covid-19 pandemic where “touch-less” interactions for things like restaurant menus increased, is to use a QR-code based trigger. In this style of user flow, a unique, time-stamped QR-code is generated which the user would scan with their mobile device. This QR-code likely redirects the mobile browser to a cloud hosted service to start the out of band authentication flow. The end user completes the authentication dance on their mobile device, and the in the background the relying party is perhaps polling the cloud authentication service in order to receive confirmation details (and perhaps an id token or assertion) that the authentication event has completed. This model is becoming increasingly common as a low-touch way to trigger the authentication dance.
Why is this an important question to ask? Well it shows that the authentication process is flexible – and can be triggered in a variety of ways. Authentication is never a one-size fits all capability – and different users and use cases will need to be catered for and a QR-code model is just another option that can be used.
4 – Are integrations to existing IDP infrastructure supported and encouraged?
In the workforce B2E (business to employee) space, existing identity provider (IDP) technologies such as ForgeRock, Ping Identity or Okta are likely to be already in place. These big dog access management components typically don’t get replaced too often. They’re often left in place for between 4-7 years – mainly as they get treated like middleware, but also because they are often used to integrate against a range of downstream systems and applications. Rewriting and rewiring those application integrations is time consuming and complex. Many IDPs will be providing single sign on (SSO), federation, session management and some basic policy based authorization services to a range of application types. These applications are likely to be a mixture of standards based (OIDC, SAML, OAuth2), cookie based (think legacy web SSO), gateway based, agent based and REST API based. This array of different application integration options allows this IDP infrastructure to provide large economies of scale and benefit many parts of the business. Authentication to these IDPs is hugely important and to provide passwordless capabilities to the widest range of application types, it is vital the specialist passwordless provider can integrate with a range of existing IDP technologies.
How this integration works of course is varied and there are no set design patterns for this. A couple of approaches is to use a standard – such as SAML or OIDC – to allow an authentication call out to the passwordless provider, which in turn would be acting like an IDP – with the enterprise IDP acting like an RP just for this flow. Another approach would be to have the existing workforce IDP call out to the passwordless provider using a non-blocking REST API call during the login event. This may slow down the login process, but allows downstream applications to essentially be abstracted from the passwordless components entirely, avoiding any unnecessary rewriting costs.
5 – Are B2E and B2C use cases supported?
One final thing to consider, is can the passwordless technology provide any economies of scale with respect to the different user community types that may require password-free technology. CIAM platforms are typically owned, operated and measured against different criteria to that of workforce systems. However, in a modern, modular and unbundled identity world, the authentication components may well be re-usable. By this I don’t mean in the same deployment, but the same technology could well be used in different B2E and B2C ecosystems.
There are of course non-functional things to consider between B2E and B2C ecosystems – namely scale, volume, transaction response time and geographical availability. Those capabilities will vary hugely between employee and customer projects. It is worth asking the question and investigating further, whether the passwordless provider is a specialist for particular user communities or generic and scaleable enough to support both.
In Summary
Passwordless authentication can delivery a array of benefits from both a usability and security perspective. However, technology evaluation can always be complex and nuanced.
Further Resouces:
The Cyber Hut Buyer’s Guide for Passwordless Authentication