The economics of credential stuffing attacks

If you run a website with a login form, you have either experienced a credential stuffing attack or it has gone undetected.

The economics of credential stuffing attacks

If you run a website with a login form, you have either experienced a credential stuffing attack or it has gone undetected.

Briefly a credential stuffing attack is when someone, automatically (most of the time) is trying to check for credential reuse against your assets.

Why ? Because the credentials increase in value depending on which websites they've got access.

The attacker tooling out there caters for everyone. From All In One applications that you can get started with 2 clicks, with Combolist As A Service, to full blown SaaS models.

Jarrod Overson's talk at PasswordsCon gives an in-depth look around the evolution and return on investment on credential stuffing.

The logical adversary

A homo adversarius, like homo economicus, a perfectly rational attacker will want to maximise their utility. If an adversary can mount an attack against a valuable asset that has no defences, for relatively minimum cost, they will.

If the cost of bypassing your defences exceeds the value of your assets, they will not waste their resources on trying to defeat your defences. Unless your assets are worth it.

This is not saying that you'll have a single adversary and that you need to go down the adversary-based threat modelling rabbit hole. But credential stuffing is a numbers game, all sorts of actors will drive by.

And the path is well known. It's your login form.

Attacker economics

We are going to use data on the average value of valid compromised credentials from keepersecurity, trendmicro, and the Akamai paper referenced above.

Let's assume that credentials on your website are worth $2.50 and you have 10000 accounts. You've decided to implement reCAPTCHA v2. The solved reCAPTCHA rate is 1000 for ~$3.00 and you can integrate with an API as well.

Assume no extra infrastructure costs and a success rate of 1%, that's 100 takeovers and a ROI for the adversary of $235. With a rate of 1 attempt per second, that's ~$79 an hour.

For a lower success rate, e.g. 0.1% , the attack becomes uneconomical. The astute mental mathematicians might have noticed that this is true, until the value of each verified compromised account is over $3. Then the attack becomes profitable again.

Of note is that most of these websites offering CAPTCHA solvers, have reCAPTCHA on their registration forms.

The common pitfall

People will jump in to solve a problem, without having a clear definition of the problem .

Organisational teams speed toward a solution, fearing that if they spend too much time defining the problem, their superiors will punish them for taking so long to get to the starting line.

And security is not exempt, especially considering the sense of urgency once an attack has taken place. In a recent study as part of a simulation, when it came to making cybersecurity decisions, the experienced players under certain scenarios, did not make better decisions to develop cybersecurity capabilities than the inexperienced players.

From the paper:

The decision-making literature suggests that there are two reasons for this poor performance: individuals' reliance on satisfactory results; and their limitations in optimization searches. The decision-making process for individuals does not involve any systematic attempt to optimize choice; instead, they tend to choose an action with satisfying results. Optimization requires a thorough search of all logical possibilities, but due to the brain's limited information processing capacity, it proves to be unsuccessful (Evans et al.,2003). These limitations can make individuals prone to reasoning bias, human error, and fluctuating emotions (Keren et al., 2003).

And by now you might already know that "companies' spending on cybersecurity does not necessarily correlate with level of protection".

For credential stuffing attacks this means: Look at the login trends, identify your users, figure out their login flows. Instead of applying a new control and mitigating or eliminating the attack, there's an opportunity to do better.

Adjust the login journey so that it provides a better customer experience whilst increasing your resilience against these attacks.

What do you do about it

I'm going to provide you with with a high-level model you can apply. Further down I also include a a non-exhaustive, in no particular order, list of defences. Use the model to identify which defences, will make sense for you.

As always all models are wrong, this is hopefully useful as well.

1. [Calculate how much each of these solutions will cost for your assets to implement. All of them. No mental maths. Write it down.]{#646e}
2. [Some of these controls can be detrimental to your customer experience or highly beneficial you need to consider
   a. You customer base
   b. Where you apply them
   c. How often you'll make your customers go through them.
   d. If the controls are going to apply on all your customers
   e. Know the number of customers, understand the effect on your product, test it.]{#b630}
3. [Based on what you have implemented so far understand how much it will cost you to implement. You now have Total Cost of Ownership, TCO = Cost of control +- customer churn/gain]{#83c0}
4. [Use your favourite risk assessment methodology or incident tracker to get the cost for the set of users susceptible to credential stuffing. That's your Annual Loss Expectancy(ALE).]{#0eeb}
5. [If you've had past incidents, there's no point addressing them with irrelevant controls. Don't throw money to the problem.]{#60c3}
6. [Pick the solution with the highest positive Return On Investment]{#1ce5}
7. [Repeat as necessary.]{#b2c4}

Note the last step, repeat as necessary, defence in depth.

And here's the list of defences, I promised earlier.

A simple and historical approach --- Honeypot fields

A field in a form that only a robot would submit or change its value. This field is for robots only. Please leave blank. In the current environment this won't be very effective, if at all.

The best known --- (re)CAPTCHA

Completely Automated Public Turing test to tell computers and humans Apart, or CAPTCHA, invented in 1997.

It looks like since ~2009 the economics of solving recaptchas haven't changed much. About ~$1-$1.5 per 1000 solved. However CAPTCHA is problematic because of its accessibility. For this reason alone, orange for example are not big fans.

Notably reCAPTCHA v3, returns a confidence interval of how likely someone is to be a person. No clicking traffic lights.

The kraken --- WAF

Web Application Firewall. If you expect that rolling out the latest version of the core ruleset and all your problems are going to go away, you're going to have a bad time.

If you're with $CLOUD_PROVIDER look at what they offer. E.g. AWS WAF

Do you run javascript --- Browser/OS fingerprinting

Your browser and each interaction with a website can reveal valuable information. Give it a try with panopticlick.

Fingerprinting techniques will try to identify via various methods your browser, OS, history, add-ons, location, and other information to identify bots. Fingerprinting-based detection is fairly complex as "bots are now using (almost) the exact same technologies as humans"

Depending on how you go about it, privacy matters and more importantly you are most likely going to be processing more personal data. You can even go to such extremes such as port scanning your customers.

Prevention --- Check with HIBP or other sources

Check your customers' passwords against passwords that have been part of a known breach. It's part of NIST guidance as well. Pay HaveIbeenPwned to use the API or download the hashes and build an API of your own. . Going down this route you also have an opportunity to inform your users and improve their overall security.

A new hope --- Passwordless and WebAuthn

Depending on the maturity of your login flow and user base, WebAuthn is great for a low-friction passwordless login. Alternatively a well controlled email verification style passwordless flow.

Two-Factor Authentication

Something you have. Even though the NCSC might suggest that if a service doesn't do 2FA you should consider changing it, customer experience opinions vary. A longer session length makes for a better experience.

Exotic solutions

Proof of work, or make your users mine cryptocurrency. Contrary to CAPTCHA you don't want to identify if someone is human, you just want to make them work for it.

Adaptive Solutions

Build behaviour models of your users. Have they logged in from a different country across the world, maybe it's time to send them an email to make sure it's them before letting them in. Can be combined with other solutions mentioned above.

Let credentials be someone else's problem

Social login. If all your users' email addresses end with @gmail.com, maybe it's worth considering adding a Google Sign-in.

Where do we go now

Attacker economics are fascinating and are constantly evolving. They can give you useful insight on how adversaries evolve against your assets and indicators on what you should do about it.

Looking at the list, you shouldn't be thinking, "oh I know X will work forever". You have an opportunity to improve your customers experience as well. Get the data and design for change.