Personal Value of MFA Devices
To minimize the risk of MFA device sharing, the MFA device should be of personal value to the user. It seems like a user's smartphone is the most personal device available, as it stores private photos, messages and other personal information that users want to keep private. Also, almost everybody has a smartphone nowadays. This is especially true for people who work in IT. Hardware tokens that only generate one-time passcodes provide no personal value to users if they are issued by their employer and are meant to be used only for work. This provides an incentive to share them among coworkers. Hence, we should focus on using smartphones as MFA devices.
As smartphones usually don't come with built-in MFA authenticators, users have to install apps that provide this functionality. Apps are software, which means that we'd be using software tokens. It is easier to duplicate a software token than a hardware token. For this reason, security folks usually prefer hardware tokens that are based on FIDO authentication protocols. During the last few years, U2F security keys became very popular. Google reported that they neutralized employee phishing by using U2F keys. Unfortunately, U2F as well as newer WebAuthn security keys are by design not able to be uniquely identified for privacy reasons. This means that users can share these security keys anonymously, as the same key will identify differently during each key enrollment. This means that we must focus on software tokens in the form of mobile apps installed on smartphones.
Popular MFA Methods for Software Tokens
Mobile apps that act as authenticators are able to provide several authentication methods. The most established methods are one-time passcodes (TOTP or HOTP), which are well known from Google Authenticator, and push notifications, which are implemented by MFA vendors in their authenticator apps. Let's explore if these MFA methods can help us reduce the risk of MFA device sharing.
TOTP and HOTP
Both TOTP and HOTP are RFC standards that require users to enroll their device by scanning a QR code. This QR code can be copied and shared. Multiple mobile devices may be enrolled using the same QR code. The party issuing that QR code has no way to identify the devices that are enrolled this way, as there is no programmatic two-way communication between the device and that party. The value of generic TOTP and HOTP with regard to reducing the risk of MFA device sharing is questionable.
Mobile push authentications are push notifications sent to a user's mobile device that enables them to deny or approve login requests by tapping the corresponding button. They offer a fast and easy user experience and have been recommended by Gartner as they provide “better user experience and lower cost than legacy 2FA methods”. There is no RFC standard for implementing mobile push authentication, hence every vendor provides their own solution, usually together with their own mobile app. This enables vendors to develop custom approaches that take MFA device sharing into account. It looks like mobile push authentication, which is enabled by push notifications on iOS and Android, are the right direction.
How to Reduce Risk of MFA Device Sharing
To reduce the risk of MFA device sharing, the authenticator app that provides push authentication should be limited to only one mobile device per user. Otherwise, the user could also install it on a non-personal mobile device that is shared between coworkers. Several nuances have to be taken into account:
- What if a user loses their smartphones and needs to install the authenticator app on their new phone? That should be made possible, but the authenticator app on the user's previous device should be deactivated.
- How is the user verified when they install the authenticator app on a new device? If this is handled loosely, then an attacker may take over the user's authenticator app by installing it on the attacker's device. The installation on a new device could be approved by the user, e.g. by contacting them through a different channel (e.g. email or phone). Alternatively, such requests could be done by an admin who is able to verify the requesting user, e.g. in person, by phone or by email. The MFA solution should inform the admin if that mobile device has been previously used by that or any other user. Having this information, the admin could see if an attempt to MFA device sharing is taking place and react accordingly.
It seems that using a multi-factor authentication product that takes the above into account would minimize the risk of MFA device sharing.
Implementation Example: Rublon
As I work at Rublon, I'm able to tell you about an implementation example of the above proposal. Rublon's multi-factor authentication allows you to enforce users to use the Mobile Push MFA method that is provided by the Rublon Authenticator mobile app. By policy, users can install Rublon Authenticator on only one mobile device. If a user installs it on a new mobile device, then it stops working on their previous mobile device.
Right now users may install Rublon Authenticator on a new device without an administrator's approval. A policy that will allow admins to enforce such an approval will become available soon. Such an approval request will tell you if that new mobile device has been previously used by this or any other user for Rublon Authenticator. This will allow you to question the user's intentions and ask for clarification.