5 questions to ask your passwordless authentication provider

Passwordless authentication is often described as improving both the user experience and security aspects of both the employee and customer identity journey. Many passwordless approaches have emerged in the last 5 years – including hardware, software, biometric and standards-based initiatives.

In November 2021, The Cyber ​​Hut published a 61-page buyer’s guide to passwordless authentication, detailing the vendor’s capabilities, requirements, integration options, B2E and B2C use cases, and migration planning recommendations.

A brief snapshot of the issues to consider when engaging vendors of software-based solutions in this space is described here.

1 – Are standards like WebAuthn / FIDO2 supported?

The discussion of whether to use open standards or proprietary approaches has been around for a long time – and affects many different areas of technology. From a security and identity point of view, many standards exist – from LDAP, OAuth2, OpenID Connect, SCIM, FIDO and more recently WebAuthn and FIDO2. Dependence on open standards can provide many benefits, from the open and collaborative way the standard evolves (many eyes, bug fixes, less chance of backdoors, etc.) to improvements for interoperability.

In the passwordless specific domain, the rise of W3-backed WebAuthn has emerged as the dominant approach to a cryptographic-based authentication approach. The standard (as of April 2021) is essentially a challenge-response based protocol that uses asymmetric key cryptography. One interaction per device/website generates two keys – one private, one public. The private key is kept safe and used during a challenge by the website against which the end user wants to authenticate. The public key – which is mathematically linked to the private – is used during the verification process. This approach has some interesting properties. First, no shared secrets are needed. Second, each key pair is tied to both the device and the relying party (or website) that wants to perform the identity verification. This helps reduce the blast radius should a private key be compromised in the unlikely event – only the associated relying party would be affected. Some good web resources to explain this process are Duo Labs’ WebAuthn.io website and Duo Security’s WebAuthn.guide.

Why is this an important question? Many passwordless approaches rely on asymmetric cryptography. While a proprietary approach does not imply a lack of security, understanding whether a standards-based approach has been considered can indicate the maturity and age of the vendor and how its roadmap for interoperability may evolve.

2 – If an app is used, where are cryptographic keys stored?

A common model for passwordless authentication is using the mobile phone as a factor of ownership—typically managed through a mobile app. The app can be generic and available in the Apple or Google stores, or it can be custom for client deployment. In either case, the end user will use the application to perform some sort of interaction with a cloud service that provides authentication response services to the requesting website or the relying party. As described above, this will likely use asymmetric cryptography – either in the form of WebAuthn or a proprietary method. An important issue to consider is where the private key is stored in these transactions. For example, the WebAuth specification describes compliant authenticators “…execute (a) on a general-purpose computing device, (b) on an on-device secure execution environment, Trusted Platform Module (TPM), or Secure Element (SE), or (c) off-device. Authenticators implemented on the device are referred to as platform authenticators. Authenticators implemented outside of the device (roaming authenticators) can be accessed over a transport such as Universal Serial Bus (USB), Bluetooth Low Energy (BLE), or Near Field Communications (NFC).“. With an app-based approach, we would assume using a TPM or SE. The general purpose aspect might involve the use of things like a trusted execution environment – so not a dedicated place but still isolated from general application usage – see for example Android’s Trusty the TEE.

Why is it important to ask? Well, it’s clearly a major security issue. Access to the private key by an attacker is essentially due to the “password theft” security level. The key must be protected against theft, manipulation, misuse, copying and removal. It’s not a good place to store it in an accessible location in memory or disk.

3 – Can registration and login use an app-less/QR-code based process?

While an app-based MFA approach is common, there may be scenarios where managing and deploying an application is cumbersome or impossible. This is probably more common in the areas of consumer, customer, or citizen-based identity and access management (see my book on the more detailed CIAM design components here). What does that mean? Well, during the registration and login processes, an end user can Not have the authentication application installed. Should that prevent them from using a service or completing a transaction? In the CIAM world, this would be considered quite a major impediment and likely result in an abandoned shopping cart scenario. A novel approach to this, which has emerged during the Covid-19 pandemic as ‘touchless’ interactions for things like restaurant menus increased, is to use a QR code-based trigger. This type of user flow generates a unique time-stamped QR code that 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 in the background the relying party may query the cloud authentication service for confirmation details (and possibly an ID token or assertion) that the authentication event is complete. This model is becoming more common as a low-touch method to trigger the authentication dance.

Why is this an important question? 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 solution – and different users and use cases need to be considered, and a QR code model is just another option that can be used.

4 – Are integrations into existing IDP infrastructures supported and promoted?

In the B2E (business-to-employee) workforce space, there are likely already existing identity provider (IDP) technologies such as ForgeRock, Ping Identity, or Okta. These large dog access management components are not typically replaced very often. They often last between 4 and 7 years – mainly because they are treated like middleware, but also because they are often used to integrate with a range of downstream systems and applications. Rewriting and rewiring these application integrations is time-consuming and complex. Many IDPs will provide single sign-on (SSO), federation, session management, and some basic policy-based authorization services for a range of application types. These applications are likely to be a mix of standards-based (OIDC, SAML, OAuth2), cookie-based (think legacy web SSO), gateway-based, agent-based, and REST API-based applications. This range of different application integration options allows this IDP infrastructure to achieve great economies of scale and benefit many parts of the business. Authentication against these IDPs is extremely important and in order to provide passwordless capabilities for the widest range of application types, it is vital that the specialized passwordless provider can integrate with a range of existing IDP technologies.

How this integration works is of course varied and there are no set design patterns for it. A number of approaches are to use a standard – like SAML or OIDC – to enable an authentication call to the passwordless provider, which in turn acts like an IDP – with the enterprise IDP acting like an RP only for that flow. Another approach would be to have the existing workforce’s IDP call the passwordless provider during the login event using a non-blocking REST API call. This can slow down the login process, but allows downstream applications to be essentially completely abstracted from the passwordless components, avoiding unnecessary rewrite costs.

5 – Are B2E and B2C use cases supported?

One final thing to consider is whether passwordless technology can offer economies of scale in relation to the different types of user communities that may require passwordless technology. CIAM platforms are typically owned, operated, and measured using different criteria than workforce systems. However, in a modern, modular and unbundled identity world, the authentication components can certainly be reusable. I don’t mean the same deployment, but the same technology could very well be used in different B2E and B2C ecosystems.

Of course, there are non-functional things to consider between B2E and B2C ecosystems—namely, scope, volume, transaction response time, and geographic availability. These skills will vary greatly depending on the employee and client project. It’s worth asking the question and further investigating whether the passwordless provider is a specialist for specific user communities or generic and scalable enough to support both.

in summary

Passwordless authentication can provide a number of benefits from both a usability and security perspective. However, technology assessment can always be complex and nuanced.

More resources:

The Cyber ​​Hut Buyer’s Guide to Passwordless Authentication

1 hour analyst inquiry service for passwordless MFA

Buyer’s Guide Launch Event On-Demand Webinar

The post 5 questions to ask your passwordless authentication provider appeared first on The Cyber ​​Hut.