Multi Factor Authentication

Multi Factor Authentication – fetch FIDO”

Written By: Andy Pantelli


We cannot simply rely upon passwords for authentication.  They can too be complex, or too simple, they can be cracked by brute force or easily forgotten.  Forcing users to change passwords too frequently results in the repeated use of a password, or in some cases users either writing them down or making a note saved to a device.   
With passwords being responsible for 80% of data breaches, and users having up to 90 online accounts study has found that 51% of passwords are reused.  Additional verification was clearly needed. 

Enter Multi Factor Authentication 

Simply by having the correct password does not Identify you, sure it’s provides authentication but that is simply not enough.  A compromised password still gives the same level of access to a malicious actor that it would to the owner of the password.  Strong Authentication, commonly known as Multi Factor Authentication (MFA) is defined by using more than authentication method; something we have, and something we know.   A compromised password is useless without the OTP sent via SMS, or a security token generated by Software or a hardware device. 
OTP sent via SMS.   

RSA Generator  

So what are the pitfalls or vulnerabilities of MFA (abbreviated to 2FA)?  The first part, “something we know” is the password which we have already detailed some of the vulnerabilities.     The “something we have” element can be the OTP sent via SMS, but his is vulnerable to SMS Hijacking or SIM Swapping attacks.  Alternatively OTP generated by Software can be vulnerable to social engineering or device compromise. 

Universal Authentication Framework (UAF) 
Universal Second Factor (U2F) 
Using these methods the Service Provider makes the determination for which type of authentication mechanism to use and make options available, including biometrics or PIN. If more than 1 factor Authentication is desired users can make use of more than one option.

How it works 

 Let’s firstly look at Registration 

1.  Registration, during the process the user chooses the method they wish to use.  Only the methods that the Service accepts are listed as options. 

2.  The user device creates a key pair, unique to this device, online Service and the user account of the Service.  The device could be a smart phone, Desktop , tablet etc. 

3.  Using the same principle as PKI, the user retains the Private Key and sends the Public key to the online Service, after which the registration process is completed. 

Illustrated above,  the user begins the logon process with username/password.  The Service then sends a challenge to the registered device, which in turn acknowledges that it has received a challenge then signs and returns the challenge to the Service. 


This is the name of the FIDO Alliances newest specifications, and was created jointly between the FIDO Alliance and World Wide Web Consortium (W3C).  Using two Open Standards Client to Authenticator Protocol (CTAP), and the W3C standard WebAthn.  Both of which work together to provide passwordless authentication, two-factor and multi-factor authentication.  Use cases include embedded authenticators such as biometrics or PINs, or roaming authenticators such as USB Device or Hard Token Generators. 
This works in a similar principle as described above, when user wants to access an Online Service for the first time a registration process is started.  Again, a key-pair is generated with a public, and a private key.  The private key remains on the device, with the public key being stored in the Online Services key database server.  For every time the user wishes to login, the Service or Relying Party uses APIs to verify credentials with the authenticator. 

1. User begins sign-on to an application. The Relying Party (FIDO2 Server) sends the FIDO client a challenge using WebAuthn requesting it to sign the data with the private key.  The FIDO client may be desktop application, browser, mobile app or other platform 

2. The user grants the request using them method chosen at registration.  The Relying Party domain is then checked against the domain registered at the time of registration.  The two must match for the process to continue otherwise an error will be displayed.  This association and a runtime check are what make the FIDO strong phishing protection. 

3. Client receives private key from the authenticator, which can be part of the users devices whatever that may be. 

4. Client signs the challenge and proves that the device has possession of the private key which then gives the user access to the Online Service. 
It may well be little known at this time, but with Alliance Members growing and the simplicity of the user experience it may well just be time to “fetch Fido” 

Stay up to date with the latest threats

Our newsletter is packed with analysis of trending threats and attacks, practical tutorials, hands-on labs, and actionable content. No spam. No jibber jabber.