Mitigating Common Identity Attacks

Attackers aren’t targeting networks anymore, they’re targeting identities. These attacks have been going on for years, but the amount of damage an attacker can do from a single compromised account has grown exponentially since the dawn of technologies such as single sign on.

That’s not to say single sign-on is bad, because it isn’t Having a centralised identity provider allows for much easier management, and much clearer analysis of user behaviour.

But the accounts need to be secured.

Below are four common attacks made against user identities, with steps to mitigate them. Enjoy.

Brute Force

This attack is the equivalent of breaking into a safe with a JCB. The attacker doesn’t need much technical skill, or even cryptographic knowledge. What they need is time, and power.

Theoretically, unmitigated brute force attacks are mathematically guaranteed to succeed. If the attacker has enough computing power and enough time, eventually they can try every single combination of numbers, letters and symbols to crack an unknown.

Unfortunately for the attacker, they are easy to mitigate against by simply limiting login attempts using account lockouts. For example, if the account is suspended for sixty seconds after every three failed logins, that will dramatically increase the amount of time it takes to crack.

Password Spray

For this attack, the perpetrator needs a list of accounts to target. This is quite easy to obtain, because email addresses aren’t designed to be secret. They then target those accounts sequentially with common passwords, in the hope that someone in the list has been lax with their password security.

Statistically, this is quite likely. An organisation of thousands of accounts will have some users using a weak, easily guessed password.

Using this method, the attacker would avoid account lockouts and look to pick of the weakest member of the herd.

Banned password lists are a good way to protect against this. Don’t give users to options to set weak passwords, instead maintain a list of words that an attacker would guess. For example, if you work at Google, it would make sense that you are not allowed to have G00gl3 as your password.

Identity providers can now also check passwords against the HIBP Pwned Passwords API, meaning when a user sets a password, the provider can check if that password has ever been exposed in a data breach. If it has, then they can make the user enter a different password.

Other mitigations involve changing the point of view. Instead of looking at the account being targeted, look at the source of the login. If you see failed logins for multiple users from the same IP, that could indicate a password spray. Use Smart Lockouts to block malicious IP addresses, and behaviour analysis to detect impossible travel activities.

Credential Stuffing

There are 938 breaches in HaveIBeenPwned, involving 17.31billion accounts.

17,310,000,000 accounts.

That gives attackers a lot to work with, and one thing we know is that people love reusing passwords. So, for example, if an attacker has a list of credentials for Canva, they might like to try them in iCloud, or Gmail, or anything else. Because chances are, some of those credentials will work.

This is called Credential Stuffing. It’s essentially taking known credentials for one service, and stuffing them into another.

Stop reusing passwords.

Use a password manager.

Seriously.

MFA Fatigue

If any of the above attacks are successful, the attacker now has valid credentials. They can log in at will, prevented only (hopefully) by the fact the user has enabled Multi Factor Authentication.

I look at all the various methods here, but I’ll dive back into one now - authenticator prompts. The process here is simple - the user logs in, they get a prompt on their phone asking them to approve the login. Just a yes/no, approve/deny. Simple.

That’s fine then, the attacker logs in, the user hits deny because they know they’re not currently signing in, and the attacker gets kicked out.

No harm, no foul.

But the attacker logs back in. So the user hits deny again. They log in again. They hit deny again. Eventually the victim gets MFA fatigue, and just wants the alerts to stop. They hit approve.

The mitigation here is to not give the user the option. Move to number matching MFA, as even if the user wants to approve the sign-in, they don’t know the number that is on the attackers screen. This is open to other attacks, but it makes the sophistication of attack required significantly higher, giving a much larger barrier to entry.

Conclusion

Because these are common attacks, they can be mitigated by implementing account lockouts, using strong passwords, and making sure those passwords are unique. They can be further diminished by protecting accounts with MFA.

Administrator's should be monitoring for breached credentials, and register to receive domain alerts from HaveIBeenPwned.

Common identity attacks are popular because they are easy to implement. Conversely, they are easy to mitigate by practising good identity hygiene. By hardening accounts, attackers are forced to try more exotic methods to gain access.