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.
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 via regedit. Update the “Duo Service: Fail Open if Unable to Contact Duo” setting in the Group Policy Object (GPO) instead.
You can easily script a registry change throughout your network if Group Policy is not available.
Do you have the right type of 2FA?
Next, evaluate whether the type of 2FA you use is appropriate for your environment. Should it require a push approval or more active data entering from the end user? This is always a balance between needs of security and with the needs of the business. This balance changes over time, so make it a point to reanalyze what is the best balance for your firm.
Microsoft is making 2FA based on number matching available for consumers but hasn’t 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, complete these steps:
- Select “Security”.
- Select “Authentication methods”.
- Select “Microsoft Authenticator”.
- Select the target users.
- Click on the three dots on the right.
- Select “Configure”.
- Select the authentication mode.
- For “Require number matching (Preview)”, click on “Enable”.
- Select “Done”.
You may wish to set up a group to test this implementation. Once you enable this setting, your users will have to launch the Microsoft Authenticator and match the numbers in the screen prompt and enter them in the authentication application on the phone.
Bottom line, even if you have enabled 2FA, re-evaluate how you set it up. Make sure attacker can’t use your default settings against you.
Copyright © 2022 IDG Communications, Inc.
