Credit: Dreamstime
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 the business alone.
But what if an attacker wants to target a specific organisation? Is their 2FA implementation good enough to protect them in that situation?
If customers have rolled out 2FA already, they 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 a banking application and text message to a 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, customers must re-review how they set up 2FA. To avoid pushback from management, they 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 cyber security 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. Key stakeholders now know these applications well enough to realise that they rarely fail. Customers most review their security implementation to ensure that they won’t be subject to this attack sequence.
For example, the defaults on my organisation’s 2FA software (Duo) were 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, users can use the Registry Editor (regedit.exe) with administrator privileges to create or update the following registry value in HKEY_LOCAL_MACHINE\SOFTWARE\Duo Security\DuoCredProv:
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. Users can easily script a registry change throughout their network if Group Policy is not available.
Do businesses have the right type of 2FA?
Next, organisations must evaluate whether the type of 2FA they use is appropriate for their 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 reanalyse what is the best balance for the 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, users must 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”.
Users may also wish to set up a group to test this implementation. Once they enable this setting, their 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 a customer has enabled 2FA, now is the time to re-evaluate how they set it up. Make sure an attacker can’t use their default settings against them.
