By Andrew Green
Multifactor authentication (MFA) is a credential verification method that requires the provisioning of two or more authentication mechanisms to gain access to an IT resource. In essence, besides a password, users log in by providing a fingerprint, USB token, a push notification on their device, or others. With this additional layer of friction, end-user experience is critical to consider when enforcing multiple authentication methods.
My personal experience with MFA has been terrible. Onboarding can be challenging, and setup instructions aren’t always clear. On one occasion, the passwords generated by the OTP app did not work. I couldn’t log in offline, and I did not know I had to download the ‘secure’ apps from the phone’s work profile Play Store rather than the standard profile Play Store. Same for consumer products. New phone number? Sorry, no more PayPal.
Getting the short end of the MFA stick put me in a prime position to research this space. I’m pleasantly surprised that across all 24 vendors we will feature in GigaOm’s Radar on MFA, this sort of experience is long gone. Moreover, even if MFA is not as hot as Edge, XDR, or Generative AI, it’s full of cool developments that immediately translate into better user experience and significantly better security posture.
Speaking of these, I reckon a lot of people would immediately think of passwordless authentication, but I won’t be covering it. Why? Because passwordless is only the result of other features and capabilities, which are much more interesting. With that said, we’ll cover two flavors of behavior-based authentication, passkeys and proximity authentication, and how MFA can be enforced on all services of an IT environment.
So far, users have been able to prove their identity by providing something they know, something they have, or something they are. But they can now prove their identity by how they behave. Within this there are two categories: the user’s idiosyncrasies, which we classify as behavioral biometrics, and the tasks they carry out, which we’ll refer to as suspicious behavior detection.
“You type really fast!” “How are they using a touchpad instead of a mouse?”
The way we interact with our devices is a fingerprint in itself. Keystroke dynamics and cadence, cursor velocity, whether we use keyboard shortcuts, and which keyboard shortcuts we use are all distinct and unique. This is an area that MFA vendors are looking to implement as a spoof-proof method that only the genuine user can replicate. Vendors such as Optimal IdM, PingIdentity, SecureAuth, IBM Security Verify, and ForgeRock are either developing this in-house, or integrating with TypingDNA, Biocatch, LexisNexis and other similar providers.
It’s also worth noting the many challenges in this area, including data protection and privacy, consistency across devices, and being vulnerable to becoming keyloggers.
Suspicious Behavior Detection
Let’s say you have implemented an authentication policy to use passwords and text messages for users logging into your CRM. You have also implemented step-up authentication to use a fingerprint for higher-sensitivity actions such as exporting, adding or removing contacts.
A sophisticated attacker may bypass the initial authentication and want to exfiltrate data. Instead of trying to export all data that would trigger the additional fingerprint prompt, the attacker goes line-by-line to either copy and paste or screenshot the entries.
In this situation, this behavior detection can determine that it’s highly unlikely a genuine user would behave this way and send another authentication challenge.
Another example would be an attacker who bypassed the authentication challenges to log into an email client. If the attacker then starts forwarding emails to outside and/or unknown organizations, the MFA will send another prompt for authentication.
We think of MFA for logging into web applications or to unlock our devices. However, MFA can be enforced on any resource requiring access, even when users are not involved. Some examples include command line interfaces, database services, cloud-based and on-premises servers, APIs, IoT devices, and homegrown applications that run locally. Depending on the policy definition engine and the richness of authentication methods, these would considerably limit lateral movement.
This is the core feature of an MFA solution such as Silverfort, while other vendors such as JumpCloud and CyberArk can also enforce MFA across different types of resources. Some vendors specialize in one type of alternative authentication, such as Corsha, which focuses on machine-to-machine authentication.
Multi-Device FIDO Credentials
In 2022, the Fido Alliance defined two more authentication types that are gaining traction in their Multi-Device FIDO Credentials whitepaper. These are ‘Using your phone as a roaming authenticator’, which we define below as Proximity-based authentication and ‘Multi-device FIDO credential’, which the industry kindly shortened to Passkeys.
Also referred to as ‘walk up and walk away’ authentication, proximity authentication is the process of authenticating users via their devices’ physical distance to a proximity token or smartphone. If the user is in close enough proximity to the token, then a prepared set of credentials is automatically verified, and the user is authenticated. This uses Bluetooth or BLE and can be achieved using a hardware token or a smartphone.
Whilst this was defined formally by FIDO in 2022, vendors such as GateKeeper have been doing this since 2015. WatchGuard provides the same result with an inverse methodology, preventing authentication if a mobile app is far from the end user’s device.
Passkeys authenticate users by tying a device to a web resource. When users create a passkey, the web resource sends a request to the user’s device, which must first be approved via the device’s first line of authentication – for example password, fingerprint, or PIN. Once the request is approved, a pair of public-private keys are generated, with the public key hosted by the web resource and the private key hosted by the device. The device ensures that a passkey can only be used with the website or app that created it. This frees users from being responsible for signing in to the genuine website or app. As such, for the user to log into a web resource, they would only need to use the device that holds the private key and provide the first-line authentication method of the device that stores the passkey.
Passkeys are being rapidly picked up by the MFA industry, with vendors such as Cisco Duo, Okta, OneLogin, Descope, Frontegg, FusionAuth, and Hypr making them available today.
MFA is getting more sophisticated, and its developments lead to better user experience and considerably improved security posture. My poor experience is, unfortunately, quite common with legacy MFA deployments. So we expect resistance from end-users when it is enforced, but also from administrators who don’t want to add more friction to an already complex IT system.
The excellent news is that with so many seamless ways to authenticate today, even those with negative biases towards MFA can select their preferred authentication method. As such, we recommend evaluating vendors’ range of authentication methods that are most suitable for your user’s daily scenarios. Even better, in known safe scenarios, like working hours from a corporate network, users may not have to authenticate at all. How about that for a great user experience?
Read more here:: gigaom.com/feed/