The Top 6 Authentication Mechanisms

Let's explore the top six authentication mechanisms that might be part of a step-up multi-factor architecture.
 

Multi-factor authentication (MFA) requires users to provide multiple proofs of their claimed identity before being granted access to some set of resources. The premise of MFA is that, if one mechanism is compromised, others are unlikely to be, so there's still some level of confidence in the user's authentication.

 

Historically, MFA has demanded a choice of authentication mechanisms from at least two of the following categories:

 

• Knowledge (something the user knows)
• Possession (something the user has)
• Inherence (some physical characteristic of the user)

 

This taxonomy is becoming less useful as more overt login mechanisms are supplemented or replaced by passive contextual models, which we'll discuss here.

 

1. Passwords

   
   A password is a shared secret known by the user and presented to the server to authenticate the user. Passwords are the default authentication mechanism on the web today. However, poor usability and vulnerability to large scale breaches and phishing attacks make passwords an unacceptable authentication mechanism in isolation. To a large extent, the value of MFA is that additional authentication mechanisms serve to mitigate the risks associated with passwords.
   
   

2. Hard Tokens

   
   These are small hardware devices that the owner carries to authorize access to a network service. The device may be in the form of a smart card, or it may be embedded in an easily-carried object such as a key fob or USB drive. The device itself contains an algorithm (a clock or a counter), and a seed record used to calculate the pseudo-random number. Users enter this number to prove that they have the token. The server that's authenticating the user must also have a copy of each key fob's seed record, the algorithm used and the correct time. The historical challenge of relying on hardware tokens for MFA has been the requirement that users always carry these tokens with them.
   
   A new form factor for hard tokens has emerged. Small tokens are inserted into the PC's USB slot. When the user needs to authenticate, they press a key on the device, which generates a one-time passcode (OTP) and sends it to the server as if the user had entered it by hand. Because these hard tokens can be left in the PC's USB drive, the users aren't pressured to remember to bring the token.
   
   

3. Soft Tokens

   
   These software-based security token applications typically run on a smartphone and generate an OTP for signing on. Software tokens have some significant advantages over hardware tokens. Users are less likely to forget their phones at home than lose a single-use hardware token. When they do lose a phone, users are more likely to report the loss, and the soft token can be disabled. Soft tokens are less expensive and easier to distribute than hardware tokens, which need to be shipped.
   
   Soft tokens leverage mobile phones' ability to generate an OTP and, possibly, their communication network. A user can demonstrate possession of his/her previously registered phone by receiving a message sent to that device. An OTP can be sent to the phone by SMS, voice call, or with an app that receives an authentication prompt via the mobile OS notification services, which is then entered by the user into a sign-on screen.
   
   The SMS OTP option doesn't require a user to own a modern smartphone that supports mobile applications, but it has several disadvantages:
   • It was never designed for security.
   • It relies on operator practices around number porting, among other things.
     It doesn't protect against phishing, although it does force attackers to implement a real-time attack.
   • It doesn't have the sort of delivery guarantee that authentication demands--a delay in delivery of minutes can effectively lock the customer out.

    

   
   In mobile-based solutions, it's more common to rely on an application installed on the mobile device. Instead of sending an SMS to the phone number, the authentication server can send a notification to the mobile app, which prompts the user for some action (e.g., 'Swipe your screen' or 'Apply your fingerprint'). A mobile app can provide useful context to the user to explain why he/she is being asked to authenticate and what he/she may be authorizing. There's a big difference between "sign on to your bank account" versus "empty your bank account."
   
   

4. Biometric Authentication

   
   Biometric authentication methods include retina, iris, fingerprint and finger vein scans, facial and voice recognition, and hand or even earlobe geometry. The latest phones are adding hardware support for biometrics, such as TouchID on the iPhone. Biometric factors may demand an explicit operation by the user (e.g., scanning a fingerprint), or they may be implicit (e.g., analyzing the user's voice as they interact with the help desk).
   
   The FIDO Alliance is defining a standardized architecture by which a user's local authentication to the device (e.g., laptop, phone) can be communicated to a server through a secure cryptographic protocol. When that local authentication is biometric (e.g., a scan of the user's fingerprint by a TouchID sensor or a facial scan or a voice print), then the FIDO model's advantage is that the biometric template doesn't have to be stored on the server, with attendant privacy risk.
   
   

5. Contextual Authentication

   
   Every time a user interacts with an authentication server, in addition to any explicit credentials they present, they (or their devices) implicitly present a number of different signals. Contextual authentication collects signals like geolocation, IP address and time of day in order to help establish assurance that the user is valid. Typically, a user's current context is compared to previously established context (or blacklists/whitelists) in order to spot inconsistencies and identify potential fraud. These checks are invisible to the authorized user, so there are no usability issues, but they can create a significant barrier to an attacker. As an example, Visa's mobile location confirmation mechanisms determine the location of the user's mobile phone to verify that the user is physically near the location where the credit card is being used. The chances of a fraudulent transaction are higher if the transaction takes place in a different location from the phone. This is an example of comparing the contextual signals of the application channel to the contextual signals of a separate authentication channel (which will typically be similar) to spot potential fraud.
   
   Contextual signals can be collected by:
   • The web pages where they authenticate.
   • The mobile devices used for MFA.
   • Other network hardware.
   • The application (or gateways in front).
   • Other sensors in proximity to the user (e.g., wearables, smart watches, etc.).
     
     

    

   Once collected and aggregated, the authentication server can analyze these signals to look for anomalous patterns that might indicate an attack or fraudulent behavior. This analysis can be:
   • Contextual, comparing a given signal value to a prescribed list of allowed or prohibited values (e.g., not allowing sign-on for any IP address coming from Uzbekistan).
   • Behavioral, comparing a given signal value to the expected value based on a previously established pattern (e.g., an employee often travels to Uzbekistan on legitimate business, and therefore is allowed to sign on with MFA, whereas any other employee is prohibited from signing on from Uzbekistan).
   • Correlative, comparing a given signal value to a different collected signal value and looking for inconsistencies between the two (e.g., according to the laptop IP, an employee is in the United States, but according to their mobile phone, this employee is in Uzbekistan).
     
     

    

6. Device Identification

   
   A specific noteworthy example of contextual authentication is for the authentication server to be able to recognize a particular device over repeated interactions. Device identification establishes a fingerprint that's somewhat unique to that device. Over time, this fingerprint allows the authentication server to recognize that device and determine when the user associated with it attempts to authenticate from a different device, which could indicate fraudulent activity. Device identification solutions create a fingerprint based on characteristics like geolocation, OS version and browser. The simplest mechanism for device identification is a long-lived cookie that is set in the mobile browser by the authentication server. The logic here is that 'I trust this device because I have seen it before and nothing bad happened.'

 

The days of one-step authentication with a username and password are gone. The digital enterprise requires you to know where they are, what network they're coming from and what application they're accessing. MFA provides enhanced security and control, and moves organizations away from a high-risk password-based security model.

Stay tuned for next week as we discuss choosing the right step-up MFA mechanism for your environment. If you're ready for more now, check out our latest white paper, MFA: Best Practices for Securing the Modern Digital Enterprise for a deep-dive into MFA and best practices.