Multi-Factor Authentication

George Santayana famously wrote, “Those who cannot remember the past are condemned to repeat it.” His words ring particularly true regarding cybersecurity issues such as passwords.

Authentication systems that rely solely on a username and password provide an unacceptably poor level of security for most Internet applications. Passwords are easily intercepted, stolen through social engineering, and even guessed. Predictable human factors result in password reuse across multiple systems, magnifying the impact of breaches. In December 2017, security researchers at 4iQ discovered a 41-gigabyte file containing a shocking 1.4 billion username and password combinations.

Adding a second authentication factor is definitely an improvement, and over the past few years many business, including Amazon, Facebook, and Google, have adopted open standards such as FIDO U2F, Time-based One-time Password Algorithm (TOTP), and HMAC-based One-time Password Algorithm (HOTP). Curiously, the finance and insurance verticals have resisted stronger multi-factor authentication (MFA) mechanisms, relying instead on significantly weaker knowledge-based factors to reinforce passwords.

Despite the widespread availability of these open technologies, the vast majority of Internet-accessible systems continue to use simple username and password schemes, and many users fail to take advantage of MFA even when offered for free. According to The Register, less than ten per cent of Gmail users have enabled it, even though obtaining access to an email account allows the intruder to identify and take over most of the user’s online accounts.

To be fair, Google leads the pack: unlike most email providers they use heuristics to identify and block suspicious behaviour. But the low MFA enrollment rate highlights a major factor contributing to weak authentication: most Internet users overestimate the strength of their password and underestimate the risk of compromise. Password systems remain inexpensive to implement, and as long as customers accept them as “good enough,” there is little incentive for developers to adopt more robust authentication systems.

Even individuals and businesses that recognize the value of strong authentication frequently struggle to implement MFA. While various open source solutions exist, they lack the ease of use and simple integration necessary to propel them into mainstream solutions. Many consist of multiple components and are too complex and expensive to deploy.

Few developers want to write their own authentication system, but until existing solutions meet modern application development requirements, they have little choice. To facilitate adoption, a practical MFA system should be available as an easily deployable virtual appliance and should leverage an open-source clusterable database to meet scalability and availability requirements.

To support web applications, the system must include an easily brandable web front-end capable of authenticating users, resetting credentials, and other management capabilities – ideally leveraging a standard such as OpenID. This will allow developers to deploy an authentication server in an isolated environment and minimize the likelihood of compromise. The fact that credentials are often stolen during web application hacks illustrates why this isolation is required.

Mobile app authentication is more complex. Many use a simple RESTful API with a username and password for authentication, but this makes multi-factor authentication difficult. For most mobile apps, leveraging a web browser window for at least initial authentication, and allowing the user to stay logged in for a relatively long time is a better approach.

Many open source projects, even those with enviable internal designs, neglect the user experience, resulting in an undeployable product. To be successful, an authentication server requires an intuitive, responsive, and attractive user interface.

Beyond application and user interfaces, a successful authentication service will provide extensible, adaptive, risk-based multifactor authentication. Rather than adopting a binary “password correct or not” approach, the future of authentication takes into account the security requirements of the application and multiple signals to make intelligent, reliable, and user-friendly authentication decisions.

For applications requiring a moderate level of security, a short numeric PIN may be sufficient for a user who has recently authenticated from the same computer, browser version, and IP address using MFA. If the user fails three login attempts, a standard MFA authentication could be required. Should the same authentication attempt originate from a different computer located on a different continent, an enhanced authentication requirement could be triggered. Depending on application security requirements, it may be advisable to block or delay the login for a period of time. An adaptable system could take into account user travel history and similar information.

On the other hand, a high-security application such as a VPN for administrator-level access to systems should require MFA for every connection. Applications with low security requirements might prompt for multiple factors only when suspicious behaviour is detected.

Other information, including IP reputation, intelligence feeds, and lists of known compromised passwords should be incorporated into the MFA system. For example, if a user logs in with a username and password exposed in a data breach, MFA authentication and a password change would be initiated.

Santayana was clearly ahead of his time. It’s 2018 and we need to catch up.


Eric Jacksch is a leading cybersecurity analyst with over 20 years of practical security experience. He has consulted to some of the world’s largest banks, governments, automakers, insurance companies and postal organizations.

Related posts

Icebreakers and the Battle for the Arctic

Marcello Sukhdeo
September 16, 2019

ISIS, Paris attack top of mind in Halifax security forum

Stewart Downing
November 20, 2015

TAPVs roll into Gagetown

Stewart Downing
August 23, 2016
Exit mobile version