Don’t Get Pwned: Stop Identity Hacks With Multi-Factor Authentication

“Have I been pwned?” It’s a question you’ve probably asked yourself before. Phishing and stolen credentials are still among the primary threat methods in breaches, and as hackers grow more sophisticated, employees and consumers have to get smarter about the credentials they use to access digital applications. On the flip side, companies also have to focus on effectively securing access to the applications people use every day.

If you’re curious to know whether your email accounts have been involved in some form of data breach, Troy Hunt’s Have I Been Pwned database is a great resource. The popularity of this service proves not just that we’re all guilty of reusing the same passwords, but that we use them across both personal and corporate resources. With weak password practices being as common as they are, it’s important to implement secure tools like multi-factor authentication (MFA).

To put this into perspective, consider this scenario. An employee has a LinkedIn account, and their employer uses enterprise applications like Office 365 and Salesforce. Imagine that a hacker was able to identify that this employee works at an organization we’ll call AtkoCorp. They then log in to the user’s inbox to send messages on their behalf, opening the door to other security threats at the organization. As we’ve shown in our Office 365 threat simulation video, this type of account takeover could be prevented by implementing MFA, even if the user is using a password they use elsewhere.

Showing the need for MFA

We start by introducing viewers to the Have I Been Pwned database, which is able to identify that LinkedIn was once involved in a data breach. Next, we see that a hacker has targeted Bruce Wayne, an employee at AtkoCorp, via LinkedIn. The hacker has access to Bruce’s LinkedIn username and password from the breach, and can use his account to verify that Bruce is on the security team at AtkoCorp.

From here, it’s not too difficult to start the account takeover process. First, the hacker tries to log in to Bruce’s Salesforce account using his LinkedIn password, but is unsuccessful. The hacker then moves on to Office 365, where users log in using their email address. Many companies standardize their email addresses to include some form of employees’ first and last name, so they’re not too hard to crack. The hacker tries a few different email and password combinations, and with no MFA in place, they’re able to log in quickly and execute the next phase of the attack.

Here’s where the real damage starts. Since AtkoCorp does not have sophisticated password policies, the hacker, acting as Bruce, can easily request a password change on his account, which is sent to his email. As a member of the security team, “Bruce” then reaches out to his colleagues to ask for access to privileged information. In this example, “Bruce” is able to log in to one of AtkoCorp’s application servers. This is simple—the hacker already had Bruce’s username and password, so all they needed was the server’s IP address.

How MFA can secure the login experience

Strong security measures like MFA can help to prevent these types of attacks. Today, Office 365 supports security measures such as federation and MFA to offer more secure logins. As part of our vast integration network, Office 365 works with Okta to keep users safe.

Now, AtkoCorp has implemented Okta’s Single Sign-On (SSO) and MFA products. So when Bruce logs into Office 365, he is redirected to AtkoCorp’s Okta dashboard, where he enters his username and password. This time, Bruce must provide an additional factor to complete the login.

Okta’s mobile authenticator app, Okta Verify—which is one of the many factors organizations can implement—offers a simple way for end users to validate login attempts. The app includes the location, IP, and browser type that the user is connecting from to determine the risk associated with the login request, and sends a push notification when needed to verify the user. In this scenario, the hacker can’t use Bruce’s account because they have no way to accept Okta Verify’s push request and falsely verify his identity.

Securing your Office 365 deployment involves more than just implementing SSO and MFA. It’s important to choose an identity and access management (IAM) solution that also includes adaptive authentication based on context. If the hacker were to try and log into Bruce’s account on a Tor browser, for instance, they would be denied as a result of AtkoCorp’s policy that blocks access from Tor.

Providing an access decision based on context creates the highest form of security, without compromising the end-user experience. In an instance where the hacker tries to log in to Bruce’s account from a location where AtkoCorp does not have an office, they would also be blocked. This is because AtkoCorp has set a policy which denies access from countries in which it does not operate.

Ultimately, protecting your end users from account takeover is best accomplished when there is no password to compromise. If Bruce were to log in from a location where AtkoCorp does have an office, there would be no box to enter a password. Bruce could enter his username and be immediately taken to the next page, where he would approve the Okta Verify prompt. In the backend, Okta evaluates the device, network, and location context to deliver a secure passwordless experience.

This Office 365 login simulation demonstrates how easy it is for a hacker to gain access to an account, and that implementing MFA is a no-brainer when it comes to enterprise security. For truly robust security, an adaptive solution that can make an intelligent decision on when to allow or deny access, prompt for MFA, or provide a passwordless login experience balances the best of security and usability.

To learn more about how Okta can help secure not just Office 365, but all your other enterprise apps, check out Okta Adaptive Multi-Factor Authentication.