Endpoint //

Authentication

10/11/2018
02:30 PM
Connect Directly
LinkedIn
RSS
E-Mail vvv
100%
0%

Not All Multifactor Authentication Is Created Equal

Users should be aware of the strengths and weaknesses of the various MFA methods.

"Two-step verification," "strong authentication," "2FA," and "MFA." Far more people are familiar with these terms today than just a few years ago. Multifactor authentication — or simply MFA — solutions are designed to protect their users' credentials and simplify password management by adding at least one more factor to the authentication process beyond a simple password. These additional factors could be something you have (such as a token), something you are (like a fingerprint or iris scan), or something else you know (like a passphrase). As credential theft has attracted more attention in the security industry, many MFA solutions have flooded the market. That raises this question: Are all MFA methods equally effective?

In truth, there's a wide range of approaches to MFA, and some are much more secure than others. Let's analyze some common MFA methods and explore which factors of verification are more or less effective:

SMS one-time passwords (OTPs): Using SMS as a second authentication factor is common. A random, six-digit number is sent to the user's phone number using SMS, so theoretically only the person with the right mobile phone will be able to authenticate, right? Wrong. There are several proven ways to hack an SMS OTP. For example, news and entertainment website Reddit was breached in mid-June 2018 via an SMS intercept. Although the hack didn't obtain much private information (and Reddit did an excellent job responding to the incident), it shows that SMS authentication is not as secure as often assumed. For example, one can intercept an SMS by exploiting cellular network vulnerabilities. Or malware installed on a victim's phone can redirect the SMS to the attacker's phone. A social engineering attack to a phone carrier may let an attacker get a new SIM card associated with the victim's number and receive the OTP message instead. In fact, US standards-setting agency NIST deprecated SMS authentication in 2016, indicating it no longer considered it a secure method of authentication. Unfortunately, the many companies that continue to rely on SMS OTPs are giving users a false sense of security.

Hardware tokens: One of the oldest MFA methods still in use, hardware authentication tokens often come in a key-fob format with a display showing time-based OTPs. The hardware itself protects its internal unique key, but there are downsides. Users have to carry them around, they're expensive, require logistics, and must be changed from time to time. Some hardware tokens require a USB connection, which can be tricky if you need to authenticate from your mobile phone or tablet.

Mobile tokens: The most common mobile tokens work like hardware tokens, but as a mobile app. The best thing about them is that the user doesn't need to carry anything other than a smartphone. The real trick is to check how the unique key gets inside it, the "activation process." Providing all keys and credentials on a QR code, such as via Google Authenticator, is usually not a good idea. Anyone that gets a copy of that QR code will have a cloned version of your token.

Push-based authentication tokens: An evolution from regular mobile tokens and SMS, the use of the secure push technology to authenticate is getting quite popular because of its improved usability. Unlike SMS, the push message won't carry the OTP. Instead, it will carry an encrypted message that can be opened only by the specific app on the user's phone. So, the user will have contextual information to decide if the login attempt in question is genuine, and then can quickly approve or deny the authentication. If approved, a unique OTP should be generated internally by the token on the user's phone and sent back with the approval to verify it. Not all MFA solutions do this, which increases the risk of a push approval message being mimicked or spoofed. 

QR code-based authentication token: While a push-based token requires a data connection from the phone, QR code-based authentication works offline and provides the contextual information through the QR code itself. The user scans the QR code on the screen with the authentication mobile app, then types the OTP that the mobile app generates based on the unique key, the time, and the contextual information. This smooth user experience is important, which is why push-based and QR code-based tokens are becoming popular. If an MFA method slows down the login process too much, people might not use it and be more vulnerable to the risks of password insecurity.

Here we can see the benefits and potential drawbacks of each type of authentication. But there are other interesting considerations when choosing an MFA solution. For example, most people would think that a hardware token is more secure than a mobile token with push and QR technology. It's not. Let's say someone from Russia tries to get through a company's VPN, using a stolen credential. If the user has a hardware token, the attacker could potentially call or send a phishing e-mail, convincing the user to give away an OTP, just by using social engineering; and a good number of users would give it. Now let's say the same user receives a push message saying something like: "Yourusername requests connection to your VPN from a computer in Russia. Do you accept?" Hard to convince the user to accept this connection, don't you think?

As you can see, there are many different types of authentication, but not all of them will give you the same level of security. A push-based token can be more effective than a hardware token, but not all push-based tokens work the same way. If you are rolling out an MFA solution, make sure you address all of these points and establish a clear understanding of what level of security and risk you're getting with your MFA method of choice.

Related Content:

 

 

Black Hat Europe returns to London Dec. 3-6, 2018, with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions, and service providers in the Business Hall. Click for information on the conference and to register.

Alexandre Cagnoni is an expert in authentication, currently focused on the cloud-based multifactor authentication solution from WatchGuard Technologies in Brazil and APAC. He has almost 20 years of experience working in the cybersecurity and authentication market and has ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
6 Security Trends for 2018/2019
Curtis Franklin Jr., Senior Editor at Dark Reading,  10/15/2018
6 Reasons Why Employees Violate Security Policies
Ericka Chickowski, Contributing Writer, Dark Reading,  10/16/2018
Getting Up to Speed with "Always-On SSL"
Tim Callan, Senior Fellow, Comodo CA,  10/18/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Latest Comment: Too funny!
Current Issue
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-10839
PUBLISHED: 2018-10-16
Qemu emulator <= 3.0.0 built with the NE2000 NIC emulation support is vulnerable to an integer overflow, which could lead to buffer overflow issue. It could occur when receiving packets over the network. A user inside guest could use this flaw to crash the Qemu process resulting in DoS.
CVE-2018-13399
PUBLISHED: 2018-10-16
The Microsoft Windows Installer for Atlassian Fisheye and Crucible before version 4.6.1 allows local attackers to escalate privileges because of weak permissions on the installation directory.
CVE-2018-18381
PUBLISHED: 2018-10-16
Z-BlogPHP 1.5.2.1935 (Zero) has a stored XSS Vulnerability in zb_system/function/c_system_admin.php via the Content-Type header during the uploading of image attachments.
CVE-2018-18382
PUBLISHED: 2018-10-16
Advanced HRM 1.6 allows Remote Code Execution via PHP code in a .php file to the user/update-user-avatar URI, which can be accessed through an "Update Profile" "Change Picture" (aka user/edit-profile) action.
CVE-2018-18374
PUBLISHED: 2018-10-16
XSS exists in the MetInfo 6.1.2 admin/index.php page via the anyid parameter.