Time for businesses to re-evaluate 2FA set-up on Microsoft networks | #microsoft | #hacking | #cybersecurity


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.



Original Source link

Leave a Reply

Your email address will not be published.

seventy three − = sixty four