MFA-Enrollment-Mistakes

Most financial institutions understand the importance of Multifactor Authentication (MFA) in keeping unauthorized parties from gaining access to user accounts. The volume of phishing attacks (designed to collect user credentials) and stuffing attacks (designed to take advantage of users who reuse passwords on other sites) is increasing steadily.

It is only a matter of time before a user password is compromised, leaving MFA as the critical control to stop an attacker. But we often find that the way that an institution has implemented MFA can leave gaps that could allow an attacker to get around MFA. The first problem we see is ineffective MFA onboarding processes.

When a user is first set to enroll in MFA, the user must be provided with an initial password that is issued by a system or an administrator. If an attacker learns what that password is, they can enroll as that user and activate MFA. We see some institutions assigning the same simple password (Password123+, etc.) initially to all new users.

Knowing this, attackers will try to log in using these simple passwords until they get lucky, then use the password to set up MFA. In extreme cases, we sometimes see institutions using no passwords at all initially or see institutions using the default password that came with their MFA solution.

Institutions should be sure to provide each new user a unique, long, complex password for every account that requires MFA enrollment, and to communicate that password to the user using an out of band method (phone calls, etc.) to reduce the chance that an attacker will be able to intercept the password in transit.

The second problem we see is that organizations sometimes set up users for MFA enrollment, then never follow up to see if the user ever enrolled. If an institution uses MFA for remote access but a user never connects remotely, the user account is at a higher risk of unauthorized remote access if an attacker is ever able to get their password. Combine this with the default and simple passwords in the first problem, and it becomes more and more likely that a compromise will occur.

Institutions should set a time limit (5 days, etc.) for MFA enrollment, and should disable the enrollment capability after that time period. If the user later needs to activate MFA, administrators can once again allow enrollment after confirming the identity of the user. This eliminates the risk of an older account being compromised due to an outdated unused MFA activation.

Recently, Russian actors have been observed hunting for and taking advantage of outdated MFA enrollments as an entry point to the network of an institution. To avoid being a victim, institutions should immediately review their MFA enrollment processes to determine if adjustments are needed. If you need assistance in performing this analysis, we can help! Send us an email at support@bedelsecurity.com.

 

Additional Resources

Multi-factor Authentication Threats Heat Up
https://www.bedelsecurity.com/blog/multi-factor-authentication-threats-heat-up

Breaking the SMS Habit
https://www.bedelsecurity.com/blog/breaking-the-sms-habit

Multifactor Authentication for Domain Admins: Start Preparing Now
https://www.bedelsecurity.com/blog/multifactor-authentication-for-domain-admins-start-preparing-now

Extending Security Controls Beyond the Office
https://www.bedelsecurity.com/blog/extending-security-controls-beyond-the-office 

Remote Employee Access
https://www.bedelsecurity.com/blog/remote-employee-access

What is Credential Stuffing?
https://www.bedelsecurity.com/blog/what-is-credential-stuffing

Remote Work Security
https://www.bedelsecurity.com/blog/remote-work-security

Office 365: A Case for Multifactor Authentication
https://www.bedelsecurity.com/blog/office-365-a-case-for-multifactor-authentication

 

What You Can do About the Okta Compromise

What You Can do About the Okta Compromise

News this week brought us word of something very disappointing, a breach in a large player in the identity services company, Okta. If I’m being 100%...

Read More
Log4Shell Response for Community Financial Institutions

Log4Shell Response for Community Financial Institutions

This post is intended to help community financial institutions appropriately prioritize their response efforts to the Log4Shell vulnerability. If...

Read More
Is Your Risk Assessment Authentication & Access Ready?

Is Your Risk Assessment Authentication & Access Ready?

In August, the FFIEC released new guidance titled “Authentication and Access to Financial Institution Services and Systems”. Because the guidance...

Read More