The challenge of multifactor authentication and shared accounts

Recently, I wrote about the importance of combining multifactor authentication (MFA) and privileged access management. According to 2018 Global Password Security Report, 45% of organizations are already using two-factor authentication (2FA) and the 451 Group reports that 53% of businesses have adopted MFA. As these numbers continue to grow, new challenges are emerging relating to authentication, shared privileged accounts and creating a virtual MFA.

Shared accounts and multifactor authentication

As a reminder, shared accounts are just that – accounts with one set of credentials that are shared across many users. There can be many reasons for shared accounts. Generally, these accounts are for IT admins or other types of privileged users to access specific platforms, network tools, such as servers, databases or third-party applications.

Take for example a billing department with multiple employees who need to access a variety of shared third-party client/customer accounting applications. The employees use shared credentials that allow them to access different systems and perform their job functions. Now add MFA into the mix – where each user needs an authentication token to access each individual system.

The MFA works by requiring a virtual MFA device that uses a time-based password on a smartphone or other hardware device be assigned to a specific IAM user or root account. Therein lies the problem with shared credentials and MFAs. Which IAM user and what phone number is the token sent to? The manager’s phone? An IT administrator’s phone or someone else’s? What does the person do if they receive the token and they didn’t request it? How do they know who on the team did?

I believe this scenario might just be the tip of the iceberg. Not only are we getting questions from customer about similar scenarios, we are also hearing from managed service providers who are tackling this same issue. For service providers who access hundreds of client systems, this can become a big headache.

One potential work around in this scenario might be to give each employee individual credentials and have them install the appropriate MFA on their devices. But this can quickly get out of hand if the billing department is managing many customer accounts and accessing numerous systems. This could require setting up hundreds of individual credentials and installing MFA hundreds of times for one user. Multiple that by the number of team members and it’s easy to see why IT departments are searching for other solutions. And eliminating MFA isn’t an option as it’s now a part of many third-party applications and a valuable security feature.

The PAM solution – MFA for privileged accounts

Emerging features in privileged access management (PAM) software help address the challenge of authentication for shared accounts. The goal is to have a virtual MFA with access control by using the PAM software to store the authentication key as a record in a reliable and safe location. This gives companies and managed service providers the option to enable MFA for shared privileged accounts. Using PAM software, the shared MFA token generation is granted to selected users using role-based access control as well as location, time and approval-based workflow.

At Imprivata, we are actively working with customers to help them incorporate virtual MFA for shared privileged accounts. In our latest release of Imprivata Privileged Access Management, we added support to store Google Authenticator App secret key in Imprivata Privileged Access Management with the option to generate tokens for shared accounts.

Here is how it works.

Using Imprivata Privileged Access Management, a user can safely store the Google Secret Key in an Imprivata Privileged Access Management record, share this record with others and with a click of their mouse, Imprivata Privileged Access Management will generate them a valid one-time-password (OTP) token. Because the Secret Key is stored in a secured record, the existing Imprivata Privileged Access Management features including role-based permissions, approval workflows and auditing trails can be used to control, limit or report access.

This new feature allows you to enforce the use of MFA when logging into the product and you can provide the ability to generate Google OTP tokens for those shared accounts that are being managed for “just in time” access.

Additionally, this is a great way to back-up your Google Authenticator secret key(s) in case your device is lost or broken.

Want to learn more about privileges accounts and virtual MFA? Check out these resources or contact us directly to see how Imprivata Privileged Access Management Development team might be able to help you address the challenges of adopting MFA for privileged accounts / shared accounts.