For many years the de-factor approach for enhancing user account security for high-risk consumer-facing applications has been to implement multi-factor authentication via hardware tokens, software tokens or out-of-band delivery via SMS or e-mail. Each of these mechanisms has their merits, and no one would argue that each provides a level of security that exceeds what is derived solely from binary authentication—the authentication using username and password exclusively.
"An adaptive approach also carries the significant side benefit of being able to improve the user experience by scaling back authentication requirements when risk is observed to be low"
However, none of these approaches are infallible, with each suffering from faults ranging from adoption and scalability to ease of bypass by a motivated and skilled threat actor. Ten years ago many of the large financial institutions were pushing customers to leverage hardware tokens for MFA. While this represented a significant step forward in terms of account security, fat marketing budgets could not overcome the usability impacts perceived by customers and adoption struggled to crack the double digits. Software based tokens integrated into consumer applications were better in that they eliminated the need for additional hardware, but customers would often find the user experience to be clunky.
These early lessons learned ushered in the age of SMS and e-mail driven MFA. From a usability perspective, these are great options. By the start of this decade smart phones had become ubiquitous and consumers were well versed at using SMS and email as core components of their everyday life, which resulted in quantifiable improvement to the resilience of consumer accounts with a manageable amount of added friction for the user. With all these positives, it is no wonder that banks, healthcare providers, email services, social networks, and other online services began to implement these capabilities in spades.
Threat actors, including criminal syndicates and nation states were not blind to this trend. Over the last three years we have seen unprecedented attention from such groups to attempt to compromise SMS delivery channels and the email accounts of individuals. SIM Swapping attacks have not become commonplace because the threat actor is interested in taking over a phone number itself, but because the actor wants to leverage that number to receive MFA messages that can be leveraged to takeover investment accounts, healthcare accounts, or other high value targets. Similarly, many wireless carriers allow users to send and receive text messages via their online account portals. This is incredibly convenient functionality for their customers but also provides easy access for the bad guys if a carrier account is compromised.
E-mail is suffering a similar fate. Individual email accounts are a constant target of phishing campaigns, credential stuffing, and other attacks designed to compromise accounts at scale. Once inside the account the bounty is not grandma’s baked beans recipe but instead an efficient and well-orchestrated inventorying of the victim’s digital life, including their social networks, healthcare providers, and the financial institutions with which these individuals have a relationship. The targets are then quickly prioritized based on the potential payout with investment accounts often amongst the first targets. The attackers will act decisively to leverage the demographic information harvested from the email account along with the ability to receive and leverage MFA tokens to take over each of these accounts and exploit them to their own financial gain.
Now that I have aired all my grievances with traditional implementations of MFA, what is the solution? The answer is simple in concept but more complex in implementation: add in the concept of risk-based adaptation of authentication policies. For all the reasons I mentioned previously, e-mail and SMS carry tremendous promise as delivery agents for MFA tokens, however, most service providers can no longer afford to blindly trust the security models around those platforms outside of their span of control to underpin the security of their own platforms. An adaptive approach also carries the significant side benefit of being able to improve the user experience by scaling back authentication requirements when risk is observed to be low.
In positioning such capabilities, one should leverage a threat model for their service to understand where the primary risk of Account Takeover (ATO) exists. Generally, this is focused in two areas: login and account recovery (password reset, and more). The risk associated with a given interaction is derived from two factors: the user itself and the device they are using, and as such risk related to each should be measured and decisioned on by a risk or policy engine. Device risk can be measured through device or browser fingerprinting techniques, IP addresses, geolocations, OS revisions, and other easily observable and low-sensitivity attributes. User risk can be measured based on transactional risk related to behaviors exhibited in recent service interactions or via external factors such that whether or not the username/credential pair appears in any recent dark web password dumps that would put the user at risk for credential re-use attacks.
To illustrate the positive user experience and security impacts of such an approach, let’s follow a pair of account recovery attempts related to an investment bank customer, Scott.
• One evening Scott is at attempting to login to his investment account from his home. He realizes that he forgot his password and attempts to recover his account. The authentication engine authenticates the device Scott is using to be the same device he has launched three other sessions from this month and notes his IP address to be one he has logged in from successfully in the past and to be in the rough geolocation of his billing address. As such, Scott is able to receive a simple PUSH message to the bank’s app and with one touch he is back on his way.
• Two months later, another account recovery attempt is made for Scott’s account. This time the attempt takes place from a device that Scott had not previously used and is associated to an international IP address Scott had never leveraged previously. In this scenario the risk engine does not allow for SMS or email MFA, instead requiring a call to customer service to answer questions based on transaction history.
The former example illustrates a streamlined user experience enjoyed by a legitimate user exhibiting low risk while the latter represents a significant step forward in improving the resilience of customer accounts and sharply reducing fraud losses and data privacy impacts. This is an approach we should all be evaluating to protect customer data and minimize fraud losses.