From cloud to on-premises access, two-factor authentication (2FA) can help keep attackers at bay. The goal is to trick the attackers into going elsewhere and leaving you alone. But what if an attacker wanna to target you? Is your 2FA implementation good enough to protect you in this situation?
If you’ve ever deployed 2FA, 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 fake authentications. Then I had to balance the needs of protection inside the office with those of allowing remote access.
Identify users with smartphones
When I first defined the requirements for 2FA, I had to find out who had and didn’t have a smartphone. Often 2FA requires a key fob as an additional factor. In the beginning, a key fob or physical device was often the only way to implement 2FA. You would generate additional manual keys which could be entered in case the key fob does not work and prevents you from gaining access. Then came smartphones and apps where you could download an app to your phone that would push an approval, number, or other action that the user had to enter or perform on the system to access it.
Some complain that 2FA’s reliance on text message to phone is insecure with attackers able to clone or swap SIM cards to impersonate a device’s phone number. Banking access, for example, typically only offers SMS messages as a second factor of authentication. When deciding between a simple password to protect your banking app and a text message on your phone, I would say a text message is more secure. An attacker would still have to go through the process of cloning or SIM swapping. In business, however, even NIST does not recommend SMS alone to secure 2FA.
Remove 2FA “fail-open” processes
Next, re-examine how you configured 2FA. To avoid executive pushback, you’ve probably set up 2FA so that if the technology fails, there are workarounds to provide access. Like every other IT admin, I configured two factors to work even if the service was down. If the cloud service that 2FA relies on to authenticate fails for some reason, this “open on failure” process allows the system to continue and not block access. Although it sounds good on paper, it was a boon for the forwards. Like a recent cybersecurity alert highlightsattackers have used it along with other techniques to gain control of a network after sneaking into a workstation.
Two-factor authentication is more mature and does not need these emergency fallback procedures. Your stakeholders are now familiar enough with these applications to realize that they rarely fail. Review your security implementation to ensure that you will not be subject to this attack sequence. For example, the default values on my organization’s 2FA software (Duo) was configured to fail if it could not access the authentication service. Other 2FA providers use the same defaults during initial deployment.
To change the fail mode after installation, use the registry editor (regedit.exe) with administrator privileges to create or update the following registry value in HKEY_LOCAL_MACHINESOFTWAREDuo SecurityDuoCredProv:
Registry Value Type Description
FailOpen DWORD Set to 1 to allow "fail open" or 0 to restrict to "fail closed".
Default: Fail open.
Duo settings managed by Windows Group Policy override any changes made through regedit. Instead, update the “Duo Service: Failed to open if unable to contact Duo” setting in the Group Policy Object (GPO).
You can easily create a registry editing script on your network if Group Policy is not available.
Do you have the right type of 2FA?
Next, assess whether the type of 2FA you’re using is appropriate for your environment. Should it require push approval or more active data entry from the end user? It’s always a balance between security needs and business needs. This balance changes over time, so be sure to re-analyze what is the best balance for your business.
Microsoft creates 2FA based on number matching available to consumers, but has not released the technology for business/Azure implementations. “Number Matching is a key security upgrade to traditional second-factor notifications in the Microsoft Authenticator app that will be enabled by default for all tenants a few months after general availability (GA).”
To enable number matching in the Azure AD portal, follow these steps:
- Select “Security”.
- Select “Authentication Methods”.
- Select “Microsoft Authenticator”.
- Select target users.
- Click on the three dots on the right.
- Select “Configure”.
- Select the authentication mode.
- For “Require Number Matching (Preview)”, click “Enable”.
- Select “Done”.
You can create a group to test this implementation. Once you enable this setting, your users will need to launch the Microsoft Authenticator and match the numbers to the on-screen prompt and enter them into the authenticator app on the phone.
Bottom line, even if you have 2FA enabled, re-evaluate how you have it configured. Make sure the attacker can’t use your default settings against you.
Copyright © 2022 IDG Communications, Inc.
