Home SecurityNetwork Security It’s time to re-evaluate your 2FA setup on Microsoft networks

It’s time to re-evaluate your 2FA setup on Microsoft networks

Source Link

From cloud to on-premises access, having two-factor authentication (2FA) can help keep attackers at bay. The goal is to get the attackers to go somewhere else and leave you alone. But what if an attacker wants to target you? Is your 2FA implementation good enough to protect you in that situation?

If you have rolled out 2FA already, you probably made some of the same decisions I did when implementing it. It had to “just work” and work well, not be too intrusive, and not allow too many false authentications. Then I had to balance the needs of protecting inside the office with that of enabling remote access.

Identify users with smartphones

When I first set up the requirements for 2FA, I had to discover who did and did not have smartphones. Often, 2FA requires a fob as the additional factor. In the early days, a physical fob or device was often the only way to implement 2FA. You would generate additional manual keys that could be entered in case the fob didn’t work and locked you out of access. Then along came smartphones and applications where you could download an app on your phone that would either push an approval, a number, or some other action that the user needed to enter or execute on the system to gain access.

Some complain that 2FA’s reliance on a text message to a phone is not secure with attackers able to clone or swap SIMs to impersonate the phone number of a device. Banking access, for example, typically offers only SMS messages as the second authentication factor. When deciding between merely a password to protect your banking application and text message to your phone, I’d argue that a text message is more secure. An attacker would still have to go through the process of SIM cloning or swapping. In business, however, even NIST doesn’t recommend text messages alone for securing 2FA.

Remove 2FA “fail-open” processes

Next, re-review how you set up 2FA. To avoid pushback from management, you probably set up 2FA in a way that should the technology fail, there were ways around the issue to provide access. Like every other IT administrator, I set up two factor to work even if the service was down. Should the cloud service that 2FA relies on to authenticate not work for any reason, this “fail open” process allows the system to continue and not block access. While that sounds great on paper, it was a boon for attackers. As a recent cybersecurity alert points out, attackers used this along with other techniques to take over a network after wiggling into a workstation.

Two-factor authentication is more mature and doesn’t need these emergency fall-back procedures. Your stakeholders now know these applications well enough to realize that they rarely fail. Review your security implementation to ensure that you won’t be subject to this attack sequence. For example, the defaults on my organization’s 2FA software (Duo) was set to fail open should it not be able to access the authentication service. Other 2FA vendors use the same defaults upon initial deployment.

Copyright © 2022 IDG Communications, Inc.

Related Articles

Leave a Comment