There exist different authentication mechanisms that might be part of a step-up MFA architecture. Some authentication mechanisms demand an explicit operation from the user, while others rely on passive collection (and so offer improved usability).

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.

These are small hardware devices that the owner carries to authorise 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 pseudorandom 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. A new form factor for hardware 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.

These are software-based security token applications, typically running on a smartphone, that 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 also easier and less expensive 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 phone (previously bound to that user) by receiving a message sent to that device. An OTP can be sent to the phone by SMS (which is then entered by the user into a sign-on screen), or an app can receive a prompt for authentication via the mobile OS notification services, or the phone can be called. A mobile app provides useful context to the user to explain why he/she is being asked to authenticate and what he/she may be implicitly or explicitly authorizing. There’s a big difference between “sign on to your bank account” and “empty your bank account.” While the SMS OTP option has the advantage of not requiring a user to own a modern smartphone that supports mobile applications, 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.

Biometric authentication methods include retina, iris, fingerprint and finger vein scans, facial and voice recognition, and hand or even earlobe geometry. Mobile devices can enable a preferred model for biometrics; the template can be stored on the device rather than the server. 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., swiping a fingerprint) or 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. When that local authentication is biometric (e.g., a scan of the user’s fingerprint by a phone sensor or a facial scan),then the FIDO model’s advantage is that the biometric template doesn’t have to be stored on the server, with attendant privacy risk.

Device identification is a process that establishes a device fingerprint somewhat unique to that device. Over time, this fingerprint allows the authentication server to recognise 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 such characteristics as 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. Device identification applications are best suited for organizations that have large populations of users accessing sensitive information from the Internet.

This process uses contextual information, such as geolocation, IP address, time of day and device identifiers to determine whether a user’s identity is authentic or not. Typically, a user’s current context is compared to previously recorded context in order to spot inconsistencies and identify potential fraud. These checks are invisible to the authorised 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 using the context of the application channel, as compared to the context of a separate authentication channel, to spot potential fraud.


Change your tomorrow, today.
Get in touch.

Google Plus