Auth & identity
August 15, 2022
Author: Reed McGinley-Stempel
Poor user experiences are directly responsible for most instances of online fraud and account takeover (ATO).
Today, 82% of all successful data breaches can be traced to the human element in online security — specifically, weak or reused passwords that can be easily used by hackers to mount credential stuffing attacks or brute-force attacks and take over a user’s account.
But users aren’t really to blame for putting their data at risk. Instead, the fault lies in the burdensome password experiences many applications put them through whenever they want to create or safeguard a new account.
In this post, we review how account takeover attacks work — and how modern auth solutions with better user experiences can help prevent them.
Weak passwords have introduced major security threats that nearly every app developer finds themselves scrambling to prevent:
Both of these strategies involve using compromised or stolen credentials to carry out an account takeover and data breach.
In a credential stuffing attack, a hacker intercepts account details — typically, username and password pairs — through a data breach. Since most users reuse the same credentials across multiple websites, the hacker can then use bot traffic to “stuff” these login details into different apps and websites on a trial-and-error basis to gain access to several of a user’s accounts at once.
In a brute-force attack, on the other hand, these attempts are less targeted, with hackers trying popular password combinations (think “12345”) at random across different accounts to gain access.
In an account takeover, hackers execute the final step to actually take control of a user’s account(s). Account takeover attacks typically have a financial motive, with the hacker using stolen accounts to directly defraud users (e.g., draining funds from their bank account) or businesses (e.g., making an e-commerce purchase that the retailer will ultimately be forced to refund).
Today, companies spend significant resources and place multiple points of friction in front of good users to reduce the risk of credential stuffing, brute-force, and account takeover attacks.
For instance, many apps integrate reCAPTCHA or hCAPTCHA technologies to detect and prevent bot activity. They may also add two-factor authentication (2FA) or multi-factor authentication (MFA) in the form of SMS one-time passcodes or TOTP to protect against account takeover once a user’s password is compromised.
To understand how applications can optimize their account takeover prevention, it’s helpful to understand how account takeover attacks work.
These attacks are attractive to fraudsters because they’re 1) very lucrative and 2) easily scalable.
For one thing, account takeover attacks are often highly coordinated operations and fueled by an entire cottage industry of fraud. Different hacker teams may each conduct one of three different steps involved in account takeover attempts.
Let’s explore these three steps in greater detail:
The applications most frequently targeted for these types of hacks tend to share two key traits:
Of course, not being “security-centric” doesn’t mean an app doesn’t care about security. It simply means that security is not the primary consideration for their product or its value proposition. For example, banking apps and custodial crypto accounts are only valuable if they can safeguard a user’s funds, so they typically invest heavily in security and are generally considered more difficult to breach. That said, hackers don’t actually need to breach the Coinbase or Chase app to steal a user’s bank account; they can just as easily get in via LinkedIn or DoorDash. More on that later.
Hackers realize that stealing a user’s LinkedIn account holds some value, but the path to monetization is much more difficult and much less rewarding than stealing that same user’s financial accounts.
That’s why, at this point, they’ll either sell the list of breached credentials to the highest bidder or invest in software that allows them to programmatically send login requests (via bots) to other apps and user accounts they’re more interested in breaching. This is one of the main reasons users are often asked to confirm they’re not a robot when signing in.
The exact method of fraud and monetization may differ at this stage, depending on the type of account that’s been stolen. For instance, a hacker can directly drain a financial account of the money within, but they may only seek to leverage a social media account to launch phishing attacks on a user’s contacts or promote specific products for a kickback.
What makes these attacks so common and dangerous is the sheer scalability of the attack vector.
If a hacker can breach 10 million passwords, validate that 20% of them were also used at a major bank through programmatic means, and then drain those accounts without ever incurring the risk of walking into a bank branch, they’ve essentially found a modern, remote, and relatively low-risk way to become a bank robber.
It’s no surprise that account takeover and online identity theft lead to massive financial losses every year. In 2021 alone, $12 billion was lost to account takeover fraud, representing a 3x increase from 2018. For context, that amount is roughly 25x higher than the worldwide fraud loss from bank robberies when last measured in 2019.
Tools like Google’s Password Checkup can be a great way to audit the security posture of a user’s online accounts. But the results of these audits can reveal just how risky a poor user experience can be and how overwhelming we’ve made it to actually remedy cybersecurity issues.
For example, the user in the screenshot above has:
How did we end up in a world where a normal user has 200+ insecure online accounts? And why are we putting the onus on users to fix these vulnerabilities, when they ultimately come down to suboptimal sign up and log in flows?
There are two critical shortcomings apps introduce to the user experience when users attempt to create an account and/or improve their account security:
Today’s users are asked to manage hundreds of online accounts, and each new password they create is required to include a complex mix of letters, digits, and symbols. It’s no wonder they look for shortcuts and re-use the same password across multiple sites, ultimately putting themselves at risk when one or more of those sites is hacked.
Most users don’t intuit the interconnectedness of online security, nor realize that an insecure password on their streaming service could actually imperil their bank account. And, given the decades of failed education on the topic, we may have to admit that they never will.
Simply put, we’re never going to convince the average user to undergo this much friction to prevent account takeover fraud. Instead, this issue needs to be solved at the application level, so users are not asked to be their own security experts.
Currently, the user experience is broken when it comes to helping users create safer passwords and making it easy to remedy cybersecurity issues. Fortunately, there are modern authentication tools available that allow apps to protect their users (and themselves) with minimal engineering effort.
Over the past few years, the tools to prevent account takeover have dramatically improved, offering a great opportunity for apps to upgrade the UX and the security posture of their sign up and log in flows.
Here are some of the key strategies app developers should consider adopting to prevent account takeover attacks and ward off popular tactics like credential stuffing:
There are two simple but concrete ways to do this right away.
Don’t allow users to enter compromised credentials in your sign up and log in flows.
There are endless data breaches exposing users’ passwords, but there are also great resources developers can plug into to detect compromised credentials. Apps and websites can turn to tools like HaveIBeenPwned (supported by Stytch’s password check API), which prevent users from re-using credentials that are known to have been stolen in a previous hack.
Or, if a user already has an existing password, apps can check whether it’s been leaked when that user tries to log in again — and force a password-reset flow if it has. Doing so compels would-be hackers to also breach a user’s email inbox, which is much more difficult given the prevalence of multi-factor authentication (MFA) on email accounts.
Move away from friction-heavy and security-light password strength estimators, and use more modern ways to improve users’ passwords.
Traditional password strength estimators follow the LUDS formula, requiring users to include at least one lower-case and upper-case letter, digit, and symbol in a new password. Unfortunately, humans are predictable, and we often end up with insecure passwords that satisfy these conditions but are exceedingly easy for machines to crack — think, P@ssword1, Password1!, etc.
Instead, Stytch uses Dropbox’s zxcvbn password strength estimator, which offers a more flexible assessment based on how resistant a password is to the latest password-guessing techniques. This feature is designed to make strong passwords easy for humans to generate and hard for robots to guess.
Every app and website should integrate some form of bot detection and prevention. Google reCAPTCHA remains the standard option, but there are also more advanced products on the market, like hCaptcha and Arkose Labs.
Any type of bot prevention is better than nothing, but if an app is still suffering from attacks on sensitive user routes, it’s likely due to the increasing availability (and relatively low cost) of CAPTCHA-solving services like Anti CAPTCHA, which make it easy for bots to bypass a CAPTCHA system if the hacker is willing to pay a minimal sum.
To make CAPTCHA solution un-bot-able, Stytch has developed a proprietary CAPTCHA solution that offers stronger protection against CAPTCHA-solving services.
Passwordless technologies are particularly powerful because they can either be layered on in a multi-factor authentication flow or used as the primary auth method while reducing user friction.
Most passwordless methods are used as secondary factors, asking users to verify “something they have” (e.g., a specific device, access to a registered email address or phone number, a YubiKey, etc.) or “something they are” (via biometrics like facial recognition or fingerprint scans) once they’ve already presented “something they know” in the form of a password.
The two major benefits of passwordless auth are its ease of use — which can improve conversion rates, lower customer acquisition costs, and increase lifetime value — and the higher cost of an attack. Unlike traditional passwords, passwordless methods are not well-suited for scaled attacks, because hackers cannot steal phone numbers, on-device biometrics, or email accounts in bulk. This considerably increases the cost of each individual hack, which is why fraudsters focus their efforts on password reuse today.
While there are attack vectors focused on certain passwordless technologies (for instance, some users’ phone numbers are targeted when attackers want to take control of their SMS inbox), these attacks are rarer, given the cost involved. They’re also easily mitigated by using the appropriate authentication method. For instance, if an app protects financial assets, its developers may choose not to offer SMS-based auth as an option, instead gravitating toward biometrics or device-based methods like TOTP and WebAuthn.
Another simple way to improve both security and the user experience is to take a hybrid approach to password-based and passwordless auth with a streamlined password reset flow. Adding a simple magic link login option (instead of requiring users to change their password entirely) gives them the option to avoid the friction of a reset and log back in with a single click.
There’s no one silver bullet that will eliminate the risk of account takeovers and data breaches — but thanks to modern auth tools, there are simple, straightforward ways that apps can enhance their sign up and log in flows while keeping their users safe.
Stytch offers a range of robust passwordless and password-based auth solutions as part of our flexible product suite.