How to Kill The Password – Buyer’s Guide to Passwordless Authentication
The Limitations of MFA
MFA Limitation
Description
Hardware Costs
Tokens and scanners have numerous costs associated with them – from high initial investments and personnel training costs to replacement and damage costs and shipping.
Silo’d Implementation
Many MFA implementations are often initially deployed against single applications – those deemed to be at most risk or perform high value transactions. It is often the case that the functionality cannot be translated to other systems either easily or without significant cost.
Poor UX
Earlier incarnations of MFA often did not have user experience (UX) as a main unique selling point – essentially selling against the security or fear angle. Help desk and support personnel teams needed to be created and trained to provide end user guidance.
Weak Reset & Rotation Support
The enrollment and issuance of an MFA modal is often streamlined to help adoption. However reset and rotation processes – perhaps where a credential has been lost or breached – often requires physical re-verification and help desk support, which increases overall cost and reduces usability.
Based on Passwords / Shared Secrets
Many MFA solutions are procured to improve password based security. As such many still rely on the use of a shared secret (password or PIN) to enrol, reset or change settings.
Inability to Innovate / Future Proof
Threats and business objectives evolve – and many MFA solutions are implemented for yesterday’s initiatives with no vision for how to handle emerging challenges and use cases.
The Rise of Passwordless
Startup Funding
Since January 2018, there has been a staggering $770 million invested over 29 financing rounds into passwordless technologies startups that claim to provide “passwordless” solutions. Whilst this number is skewed by the $543 million Transmit Security received in June 2021, it still resembles a large innovation pattern in the bid to rid the world of password based authentication.
Mobile Adoption
Apple introduced “Face Id” to the iPhone in late 2017 as a means to provide a more seamless experience regarding the operation of the mobile device. It was envisioned that the act of unlocking a device would become “free” – in the sense the end user had to look at the device anyway to operate it, so by augmenting the same process for authentication, the act of entering a PIN or swipe would be removed. Face Id was added after the iPhone’s initial biometric system was introduced for fingerprint identification with Touch Id in 2013. Android adopted similar capabilities in their operating system with the likes of the Samsung Galaxy 5 leveraging fingerprint login at a similar time to the iPhone. With Android 10 and above, support was added for face based authentication. This ubiquitous expansion of biometric technology in the mobile, provided a basis for improved end user education and adoption of password-free login approaches.
WebAuthn
The W3C (World Wide Web Consortium) is a standards body focused upon developing the web for the greater good
The W3C Web Authentication working group was created to focus upon providing a cryptographic based challenge response style authentication protocol that did not rely on passwords.
The working group was supported by employees from the likes of Google, Mozilla, Yubico, Nok-Nok Labs, Apple, Paypal and IBM amongst others.
The development of standards tackling the issue of authentication in a password free realm has increased awareness, adoption and design patterns that are independent, open and peer reviewed, allowing organisations to make procurement decisions that are often separate from proprietary technologies.
Passwordless Technology Options
Passwordless “Experience”
The passwordless “experience” refers to an MFA flow, where an initial authentication event is based on a known factor such as a password or PIN but subsequent authentication events do not leverage the password. This provides a mechanism for elevated trust to be gained and sustained – perhaps via mechanisms such as allowing the end user to “trust this machine”. If that machine or browser then alters for future logins, the authentication process reverts back to leveraging a password.
Capability
Description
Persistent Cookie
A cookie placed into a web browser by a server side application that still exists after the session with the back end service has expired. This allows the end user to revisit the application, with the persistent cookie providing details such as username or other device related context. Whilst the persistent cookie lasts longer than a session cookie, it does have an expiration time and will expire eventually – perhaps a month or 12 months from issuance.
Capability
Description
Push Authentication
This is a mechanism in which an authentication event is triggered by the end user via a web site interaction and a notification is “pushed” via an out of band communications method to a pre-installed mobile application. The push is typically for notification and the end user will perform a nominal interaction – typically a swipe or confirmation that they wish to log in. The security aspect is driven from the fact the communications method is separate from the login method and the affirmative action cannot be spoofed if the device is in the hands of the original user.
Capability
Description
OATH OTP
OTP (one time passwords) can be generated in several ways. The OATH (open authentication) approach removes the need to transport codes and instead allows them to be generated locally on a device, typically via an app. The server side computes the same OTP based on a shared secret and a timing component (for TOTP) or a counter value (for HOTP).
Capability
Description
OTP via SMS
In this process the OTP is generated server side and transported to the end user via a text message. The generation of the OTP should leverage a value unique to the user along with a dynamic value. This method is actively discouraged by the likes of NIST if the SIM and device cannot be authenticated separately due to the possibility of compromise of the Public Switched Telephone Network.
Capability
Description
OTP via Email
In this process the OTP is generated server side and transported to the end user via an email message. The generation of the OTP should leverage a value unique to the user along with a dynamic value. This method is actively discouraged by the likes of NIST access to the recipient’s email address is not restricted to a particular device and could be open to adversarial activity.
Pure Passwordless
Pure passwordless technology has no reliance on a known factor such as a password. In this scenario, the entire authentication event relies on a combination of something the user is and typically something they have.
Capability
Description
Security Key
Generally in the form factor of a USB fob, the security key is used to generate an asymmetric key pair, with the private key aspect never leaving the hardware. The public component is made available to authentication verifiers. During an authentication ceremony the verifier challenges the security key to sign a response back to the verifier using their private key. The verifier confirms authentication by using the corresponding public key.
Capability
Description
Biometrics
Biometrics come in many forms, with the fingerprint scanner and facial recognition aspects of both the iOS and Android mobile operating systems being the most common for consumers. Dedicated hardware can be used in the workplace for fingerprints. Biometric authentication can be local and native (meaning the captured biometric template and subsequent comparisons during login never leave the device) or server side and more global (as seen with dedicated fingerprint scanning databases as used by law enforcement or border patrol). Emerging biometry design leverages the mobile for capture and distributed storage for the template that is created, removing a single point of failure.
Capability
Description
SIM
The SIM (subscriber identity module) in many mobile devices can be used for authentication between the device and the MNO (mobile network operator). SIMs are provisioned post production with symmetric keys which are used in a challenge response style protocol managed by the MNO and the local base station. This process can be integrated into a broader proof of proof of possession style authentication event through ownership of the SIM and corresponding telephone.
Capability
Description
FIDO/FIDO2
The FIDO Alliance promotes the use of public key cryptography as a means to provide a secure challenge response based protocol for authentication. A key pair is generated and the public key is stored by the verifying website. The private key is kept secure (within a security key, mobile phone or a tamper resistant location within a laptop). Other common aspects of FIDO include U2F (Universal Second Factor) and UAF (Universal Authentication Framework). More laterally FIDO2 has emerged with two decoupled components – a web aspect (W3C WebAuthn) and a hardware communications aspect (CTAP – or client to authenticator protocol). FIDO certified security keys are available.
Capability
Description
Magic Link
Magic Link authentication typically leverages a user initiated event – such as the entering of an email or userId into an application. The backend application generates a unique and time bound URL that typically contains a component that is pseudorandom. This URL is sent to the user’s pre-registered email – where the user can click the link. The backend service validates the link and expiration and “automagically” logs the user in if verified, issuing a session or cookie in return. Clearly this process requires strict security of the recipient’s email account and there is nothing to prevent link sharing or worse – link theft via man in the middle or adversarial access to the email account. Magic links are useful however if used by infrequent users – or perhaps used only for limited access requests and account recovery flows, if combined with secondary checks.
Capability
Description
Smart Card
Smart Card based authentication falls into the possession factor aspect – and is often consolidated with a biometric or sometimes a PIN – albeit the PIN should not be leveraged on its own. The card will contain an integrated circuit – either with an exposed contact module for contact with a reader, or in built antennae for contactless data flow. The card will contain pre-provisioned cryptographic keys that can be used for challenge response style authentication – either encrypting responses if using symmetric keys or perhaps signing a response if using asymmetric. The card needs to be issued via a secure enrolment process which is typically performed by a physical issuance ceremony – perhaps where government issued identity documents are verified.
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
