Striking A Balance With Multi-Factor Authentication

The Multi-Factor

Access security is a fundamental and critical element of corporate risk management. Strategies for all aspects of user interaction need to be in place; internal employees, external 3rd party service agencies, and customer accounts all demand appropriate authentication schemes. A failure to properly authenticate a user could lead to an immediate security breach having critical systems under an attacker's control with elevated privileges. Even a breach of a low-level user account, such as a website user account, can lead to serious data loss and loss of reputation. 

Multi-factor authentication (MFA) schemes are the current status quo for providing increased access security. Keep the bad guys out by requiring a user to provide an additional form of authentication to verify their identity. MFA mitigates a lost or stolen password and prevents attackers from easily accessing protected account space. Most commonly, this is done by sending via an OTP (one-time passcode) using a 2nd-factor authentication application on a user’s phone or by SMS message, thereby proving that the user is also in possession of their primary mobile device. 

Other forms of MFA include biometrics, answers to pre-defined security questions, and physical authentication tokens. More broadly, MFA authentication methods are broken down into the categories “Thing You Know” such as a password or pin, “Things You Have” such as mobile device, or access to an email address, and “Things You Are” such as fingerprint scanner or other biometric. 

Considering all the options, striking the right balance between usability and security is an important consideration. Too little can lead to a security breach of private assets, while too much can leave users frustrated and burden usability. Let us inspect some use case scenarios of MFA implementation to analyze the potential benefits and drawbacks. 

Striking Security Level Balance - Use Cases

CASE 1: Not enough - Company A uses a combination of passwords and a security question. 

Security questions can include user-defined questions and pre-defined questions. Examples of standard pre-defined options often include birthday, mother’s maiden name, elementary or high school name, favorite teacher’s name, and city born in. Allowing a user to define their security question leaves the door open to even less secure options. In these cases, a quick OSINT search on the target could reveal accurate answers. For example, if a user’s contact list is available on a social network, a mother’s maiden name could be obtained by searching and surmising that one of the most common last names would be the correct answer.

 Similarly, birthdays and cities of birth are often part of a user profile. Thus, the burden of a social engineering attack to obtain answers is also reasonably low. Posing as an attractive potential relation or phishing with an attractive product deal could lead users to offer up information readily in an application form or short conversation.

 This method lends ease of use but at the expense of security. It’s clear that if Company A is protecting PII or otherwise secure information, this MFA scheme is not robust enough to offer high security. On the other hand, if it is little or no critical data protected, this solution offers slightly more security than only username and password. 

CASE 2: Good balance Strong Security - Company B uses a combination of password and MFA with either email, mobile app, or SMS OTP code. Backup codes are also provided for emergency use. When users log in from a new device or from a new geo-location, they are prompted to verify their identity using one of these MFA methods. Company B also allows users to configure MFA as a requirement for every login. 

In this case, the user can opt into their own security protection, but access is monitored regardless and MFA is used when certain high-risk circumstances arise, such as a user logging in from a new device or IP address. In the case of a lost device, the provided backup codes allow temporary access until the user replaces their device. The balance provides a high level of security and ease of use. 

CASE 3: Perhaps too much - Company C sells desktop computers, laptops, mobile phones, and IoT devices. They track and aggregate device ownership linking all devices a user owns. When logging into a web console or after a set amount of time on each device, an extensive authentication process takes place, requiring users to validate their identity on at least two devices in their ecosystem. The user must provide their web account username and password, device login password, and enter a second device's login password. Finally, the user must also enter an OTP delivered to a second device. Finally, the ability to copy and paste passwords into the input field has been disabled in an attempt to prevent bots from filling in a login form. 

In this case, the user is put through a gauntlet of identity and device possession verifications. This approach amounts to providing 3 separate passwords and verifying the possession of at least two separate devices. Although the process appears highly secure, it's questionable whether more security is realized. 

The user experience is interrupted by a process that feels unnecessary and repetitive. The reality is that an advanced threat-actor can easily disable code, preventing copy-paste and even imitating keystrokes and mouse movements into the user interface. Further confiscating usability is the fact that users in possession of only one ecosystem device will not be able to complete the authentication, leaving them without authentication means when they are on vacation or otherwise away from their desktop or laptop. Although C-level executives may be happy to hear that "All precautions are being taken," the reality is that the user experience is suffering unnecessarily without much gain in security. 

Spend your energy and assets where they are needed the most. Avoid collecting sensitive data from users if your business model does not warrant it. Avoid disrupting the user experience with security mechanisms that do not provide viable security. Finally, and perhaps most importantly, application architects need to have a deep and thorough technical understanding of authentication security mechanisms to strike a good balance between authentication security and usability.