Following on from our blog on Implementing Multi-Factor Authentication, here we will look at the further security offered by Passwordless Authentication.

Microsoft has been promoting Passwordless Authentication since mid-2021 (with Google following suit late-2022), and while roughly half of businesses in 2023 were planning the move, only 13% of those had fully implemented the change. This means that nearly 94% of all the responders are not deploying, or have only partially deployed, Passwordless authentication.

Passwords, as a single point of protection, are notoriously weak. Even if a user isn’t caught by a phishing attack, it’s highly likely (90% of users) that they are re-using their passwords elsewhere, on vulnerable systems. It’s even possible that it has been previously skimmed from a vulnerable source and the details are already for sale on the dark web. It’s safer to presume the password will be compromised at some point and remove the risk altogether.

There are many ways to leverage Passwordless access; two of the most common are using a FIDO Passkey (often a USB device activated with a fingerprint), and an Authentication App (most likely on your mobile phone).

Passwordless Authentication

Passwordless authentication using the FIDO 2 method has its foundation in asymmetric encryption – a mathematical algorithm utilising one-way functions to generate a pair of keys; referred to as a private and public key. Anything encrypted with either key can only be decrypted using its pair. The private key is secured on the users’ FIDO Passkey while the public one is stored with the service. The authentication process can differ slightly depending on the resource you’re accessing, but in general looks like this:

    • The user requests access to a service with their username or ID
    • The service sends a challenge message – typically a random series of characters
    • The user’s system employs its private key (FIDO Passkeys are often secured using fingerprint recognition or a PIN) to encrypt the message and sends it back
    • The service then decrypts the challenge message with the public key and, if everything is correct, the user is authenticated, and a security token is shared with the users’ device providing access

The length of each key in a pair is, at least, hundreds of characters. Their actual length is dictated by the security protocol being used. The security token is used to reduce the number of authentication requests made and can be set to expire based upon your security requirements.

Passwordless security via an Authentication App also employs asymmetric encryption. It securely stores the private key on the mobile device (probably a mobile phone) while the public one is secured with the service. The authentication process is similar too, but as the authenticator device isn’t directly attached to the user’s computer, there are additional steps to ensure the authentication is linked to a legitimate request, and not a bad actor attempting to gain access to your system.

I’ll describe the Microsoft Windows 11 process for detail, but other providers support their products in a very similar way. Presuming Passwordless authentication via the Authenticator App has been configured correctly, the process is:

    • On the Windows 11 sign in screen the user types in their username and selects the Authenticator app to sign in 
    • The computer sends a login request to the server which returns a QR code to use with the Authenticator app. The authenticating server also sends the data contained within that code to the App for comparison 
    • Using the Authenticator App to read the QR code and confirming a match, proves the sign on request is legitimate and that the computer and mobile device are being used in tandem. It’s worth noting that the mobile device (again, likely a phone) should implement biometric security to restrict unauthorised access 
    • The “challenge” message exchange described above is repeated, only this time between the authentication server and the mobile device and once approved, the authenticated token is sent to the users’ machine, providing access to the system 
Passwordless Authentication

Passwordless is a great solution to securing your systems, but it isn’t without its issues. Losing your FIDO key or Mobile phone means you’re effectively locked out of your account. Self service solutions to recover access often need to bypass the added security, providing a point of weakness to your system. Having multiple FIDO keys will help (one for use, and one in a safe place) but it’s worth working with your internal IT Team or MSP to recover any lost accounts and keep the Self Service Recovery feature turned off.

Deploying Passwordless authentication requires some level of infrastructure. It’s most flexible in the Cloud, with pretty much all the providers (AWS, Google, Microsoft, etc) supporting, FIDO authentication, with Microsoft supporting Passwordless authentication on-prem. All the providers also have their own flavour of Passwordless security which can be used to leverage some of your current hardware, such as Microsoft Hello, employing the biometric features built into your laptop.

With so many options available you’re sure to find a solution that fits your specific needs and finally make passwords a thing of the past.

For more information on security, and to see how Vissensa can help, click below.

FAQs

What is Passwordless Authentication?

The process of verifying a software user’s identity with something other than a password.

How Does Passwordless Authentication Work?

Instead of passwords, identity can be verified based on a “possession factor”, or an “inherent factor.” Possession Factor uses possession of an object that uniquely identifies the user whilst Inherent Factor uses a person’s biometric signature.