Introduction

Some people have probably heard of the term MFA, but for those that haven’t, put simply this is the acronym for “Multi-Factor Authentication”, but is also known as 2FA for “Two Factor Authentication” which indicates using two factors for authentication. The purpose of this is to increase the security of user’s accounts to ensure that in the event of a breach of a single factor, passwords for example, there are other steps (factors) to validate the user’s identity before access to their account can be gained. Once all required factors have been validated, access to their account is then allowed.

 

MFA Types

There are different types of factors to validate a user’s account and these could depend on the configuration on a site-by-site basis, or even on a user-by-user basis.

However, not all sites have the MFA option enabled, even though the UK government guidelines such as Cyber Essentials steer companies towards using them. MFA generally consist of a code which gets presented to the user, but not all show the code to the user.

The typical options could be by one of the following means:-

SMS

 

Email

 

Authenticator App

Hardware Keys (YubiKey)

 

 

How MFA works

The way MFA works is once a user has entered their credentials, before being allowed to access their account there are one or more further steps which need to be validated and this generally involves having to give a code. Once this code is validated, access to the user’s account is granted.

The way that the code is provided to the user can differ and in most cases that code is visible to the user so they can enter this in to be validated. With both SMS and Email, once the user has entered their credentials and these are validated, the site sends a code for the user to enter at a further step. Then once this is validated, the user is granted access.

Using an authentication app differs slightly from SMS/Email as instead of receiving a code after the user credentials are entered, the user can see the current key that is required as these are continually generated by the app.

Unlike these, hardware keys differ further as they don’t make the codes visible to the user, instead, the site asks the user to insert and tap the key and that’s it. This is by using the unique cryptographic key built into the device which is used to generate codes to confirm your identity.

As the available options can depend on a site’s configuration as previously mentioned, a common way of providing MFA is by the first three options in the above list. It should be noted that the option of allowing the use of a hardware key is not widely implemented yet except for some early adopters.

A site having an MFA option available would have one or more of the above-listed options, however, sites can also have functionality which could mimic MFA without having MFA configured. An example of this could be when you try and log in to a site from a different location. The site knows that a login attempt has been made, but the location of the requester is different to the typical location where logins happen. Thus, the site asks the user to validate this typically by acknowledging an email to accept the location where this request is coming from.

 

Conclusion

Typically there are drawbacks to each option. These drawbacks could range from how a code is transferred and the security thereof to the user’s preferences or personal views on the makers of the authentication app, to the cost involved in implementation. However, despite any of the drawbacks of any method, it is generally agreed upon that having some form of MFA is better than having nothing at all.