Industry

8 Things To Avoid When Building Account Takeover Prevention In-House

In the past two years, account takeover attacks have evolved dramatically. One recurring theme we’ve seen is that gaps often emerge when the security program’s focus is misplaced. For us, it starts and ends with protecting the user—which means the emphasis has to be on protecting the user account. But great security doesn’t have to come at the expense of great UX. We put together this checklist to address some of the common mistakes we see when it comes to user account security and account takeover prevention—and provide solutions to help bridge those gaps.

  1. Don’t just look for attacks in single IP addresses. Most attackers have evolved away from the single IP model, so you aren’t just going to see brute force attacks coming in from a single IP. These days, it’s fairly easy for hackers to acquire entire IP ranges (we’ve seen attacks with over 100,000 IPs, many of which are registered in the United States!) to masquerade as traffic, dubbed a “slow and low” attack. This strategy greatly reduces the efficacy of rate limiting and location-based rules because you’d need to tighten the thresholds to a level where you’d be locking out legitimate users. In order to catch these attacks, try analyzing attempts on the ASN or ISP level instead. Just keep in mind that a large part of the internet population is sharing a limited set of IPs from popular ISPs such as AT&T and Comcast, so it’s good to build up a sense of the reputation of any ISP or ASN accessing your site before blocking it (e.g., count the number of successful login attempts in the past 24 hours), since freezing accounts from these providers and preventing access to the site will deteriorate valid users’ experiences.
  2. Don’t allow malicious IP whitelisting. To further prevent their IP activity from being detected and blocked, attackers sign up for new accounts and run successful login requests from them to make these IPs look legitimate. It’s not uncommon to see these types of accounts having hundreds of thousands of successful login attempts. You can limit this behavior by only letting each user contribute once to successful IPs. So even if they do a hundred thousand logins, you’ll only count the first one toward your total stats.
  3. Don’t lock accounts based on outside activity. This will make it possible for attackers to lock user accounts without even having the correct password, essentially causing a denial of service. You shouldn’t lock an account until there’s a successful login.
  4. Don’t check the absolute number of (failed) logins. During spikes of heavy traffic—when there will be more failed logins, but also more successful ones—be sure to keep an eye on the ratio of failed logins vs. successful logins. Otherwise you might risk triggering your rules when there’s just a general spike in traffic, e.g., from a flash sale or new email campaign.
  5. Don’t get sloppy with your password reset flow. Be sure you aren’t exposing the valid email that’s part of your database in the password reset flow. Remember, hackers want to understand whether they have valid account emails. In brute force / credential stuffing attacks, a hacker tries multiple email / password combinations to unlock a legitimate account. When you expose valid email addresses, this allows hackers to narrow down the list of credentials they have to try and steal more accounts in shorter timeframes.
  6. Don’t allow login requests outside of the browser. Many attackers are utilizing lightweight HTTP clients like Curl to scale their attacks. Having a JavaScript set a cookie in the browser and checking it during login ensures that the attacker needs to use a real browser in the attack, which is harder for them to scale. But you need to make sure the same cookie can’t be used twice, because attackers will figure out how to use the same cookie multiple times to mimic a browser.
  7. Don’t exclude mobile traffic. The last advice told you to set a cookie in the browser. This is a bit trickier on mobile, which is why sites end up whitelisting their mobile apps entirely to avoid risking users getting locked out. Hackers are using the fact that many applications aren’t looking at the mobile traffic since it’s harder to deploy mitigation flows (such as CAPTCHAs) into the mobile app. So hackers sniff mobile requests, copy the mobile user agent, e.g. “Company/7.0.0 (iPad; iOS 11.2.6; Scale/2.00)”, and then use it in the attack to circumvent the rules that you put in place to only work on web.
  8. Don’t just rely on marking logins “safe” with CAPTCHAs. CAPTCHAs are a popular way to protect your login endpoint from bot activity. However, CAPTCHAs will only tell you whether the CAPTCHA was solved or not, which can be automated by CAPTCHA-solving farms such as 2captcha.com and deathbycaptcha.com. Instead, you need to ask the user about the login attempt since they’re the only one that really knows whether a login came from their device or not. (We actually advise our customers to remove CAPTCHAs entirely since they give a false sense of security and is annoying to the end-user.)