Authentication-Based Defense

So now we’ve trained current employees and added anti-phishing training as part of onboarding for new employees. We’ve used DNS-based defenses so that incoming phishing emails can’t be forged to look like they came from our domain. What else can we do to defend ourselves? We’ve done everything we can do to decrease the likelihood of lost credentials. Now let’s see what we can do to reduce the impact of lost credentials.

2FA

In a traditional login, a user supplies a username and password to authenticate themselves to the system. In this scenario, the password is the single factor the system uses to decide whether to authenticate the user or not. That works fine until the password becomes known to an attacker. This disclosure lets the attacker log in as a legitimate user. If the system had a second factor to be used in addition to the password, then disclosure of the password would not compromise the account. This is the idea behind two-factor authentication (2FA).

TOTP

The most common type of 2FA is a time-based one-time password (TOTP). In a TOTP system, the server and the client share a second secret in addition to the password. During login, after the user submits the password, the user uses the 2FA application, which uses the current time and the shared secret to generate the time-based one-time password. The user submits this second password, and the server, which knows the current time and remembers the shared secret, can perform the same derivation and make sure that the second factor is correct.

TOTP Limitations

Adding 2FA to our logins can provide some defense against phishing. An attacker might steal a username and password, but without the second factor, they can’t log in. This stops the effectiveness of simple password theft and can make attempts to use the newly stolen password stand out. But, depending on the type of deception used in the phishing email, it might not be enough to stop a more sophisticated attacker.

Consider a phishing campaign where the phisher wants to exfiltrate data out of a web-based system that’s protected by 2FA. All the phisher needs to do in addition to the normal credential stealing is to convince the user that they need to supply the second factor as well. This can be done with a Man-in-the-Middle style attack. The phishing email will contain a link to a login look-alike web page under the phisher’s control, just as in a normal phishing email. This page will then steal the username and login, store it, submit those credentials to the legitimate login site, and present the user with a lookalike 2FA button. Since the legitimate login site received valid credentials, it will challenge the legitimate user with the 2FA challenge button. But in this scenario, the user already thinks they need to log in. They’re expecting the 2FA challenge, so they supply the second factor, thinking that it’s authenticating the login process they’re seeing on their screen. But instead, it’s authenticating the login process initiated by the phisher’s website.

The presence of 2FA makes this attack harder to pull off. There are more moving parts, there is a second opportunity for the user to decide not to authenticate, and the legitimate website will know the IP address that the phishing site is connecting from, which could raise alarms. But these challenges for the phisher are only speed bumps. None of them actually prevent the attack.

Prefer non–SMS-based 2FA

There are a variety of 2FA options. Apps that run on your smartphone seem to be the most popular. Some of the smartphone-based 2FA apps communicate over SMS, which isn’t ideal. Phone companies can be social-engineered into making account changes. And attacks on the cell phone network itself are possible.

You’re still much better off with SMS-based 2FA than with no second factor. But if you have the choice, pick a non-SMS system. Requiring 2FA for logins helps decrease the value of stolen credentials. It also helps in the face of credential-stuffing attacks.

U2F

U2F is a more advanced form of 2FA. It is an open standard designed to address a couple of the shortcomings of typical 2FA. First, U2F is not phishable. Whereas a TOTP client trusts the server implicitly and hands over the TOTP automatically, a U2F client performs a handshake, not unlike the TLS handshake. This lets the server and the client authenticate each other. If the server is an imposter (as is the case in phishing attacks), it will fail this authentication step and won’t gain anything that will help it log in to the website it’s impersonating. Second, U2F clients are small, purpose-built devices. The most popular variety is the YubiKey line of U2F devices from Yubico. They’re generally about the size of a small USB thumb drive. They only have the ability to perform the U2F handshake. They don’t have a full-featured operating system with the ability to run apps like a smartphone, so they’re much harder for an attacker to compromise. Typical TOTP 2FA applications run on either a phone or a regular computer. If either the phone or the computer were to be compromised through targeted malicious software, the 2FA app could become compromised too.

Joe asks: What is credential stuffing?

Credential stuffing is an attack that targets password reuse. After a breach that results in a large number of leaked usernames and passwords, attackers can try those username/password combinations against other online services. This attack is effective because password reuse is so rampant that it’s almost guaranteed that some of the username/password pairs in a large credential dump will be reused for other websites. It’s also effective because it doesn’t look like a brute force attack to defenders: it looks like a single failed login attempt for a targeted account. Legitimate users mistype their passwords all the time; you can’t sound the alarm every time someone mistypes their password.

For more information about credential stuffing, see the OWASP writeup.

If you have the option, choose U2F. There are a couple reasons it may not be the right option for you today, however. Though adoption is increasing, it’s not supported on every platform just yet. Another downside is that it requires purchasing a small hardware device for every person in your organization. And then it requires that every person in your organization have this device with them whenever they want to use protected services.

In-application defense

Once you have 2FA in place, you’ll definitely want to require it for login. In fact, 2FA at login time is what most people think of when they think of 2FA. But 2FA can also be required by applications before allowing particularly sensitive operations. Examples of sensitive operations include changing passwords, changing the email address used for the current account, and transferring money. Requiring 2FA for sensitive operations means that even if an attacker got past the login 2FA (for example, by physical access to an unattended, logged-in computer, or by Man-in-the-Middling a TOTP login), the phisher would need to bypass 2FA a second time, which is difficult.

Another defense for highly sensitive operations is a four-eyes check. In a four-eyes check, two different people must give approval before a system will perform highly sensitive operations. These approvals are audited. This significantly raises the bar for an attacker.

The four-eyes check and the additional 2FA challenge are both strong defenses. Additionally, they are both noisy defenses. Attacks that are stopped by either of them leave behind clear, high-quality signals for later analysis. Unfortunately, they must be used sparingly because they carry such a heavy usability cost. They can only be added to the most sensitive operations.

If you use a cloud hosting service like AWS, you’ll want to protect your AWS admin accounts with 2FA. These account credentials are just about the most important data you have. If the credentials for these are leaked, or if the admins reuse credentials from another site that gets compromised, then attackers will be able to take over your entire cloud infrastructure.

                                                 Q U I Z