Credential stuffing protection for mobile apps

What a credential stuffing attack actually is

The attacker starts from a list of username and password pairs leaked from another service and replays them automatically against your login API. Nothing is guessed: the attack rests on the fact that some of your users reuse passwords. That is why it works even against a strict password policy.

According to Okta's The State of Secure Identity Report 2023, one in four logins analysed was an attack of this kind. The proportion climbs in banking, fintech and e-commerce, where a working account has immediate value.

The cost does not start when the attacker succeeds. Every attempt consumes backend capacity and, if your flow sends an OTP before it validates the origin of the request, real text messages that you pay for.

Why the usual controls fall short

The three classic controls share the same weakness: they decide after the fact, on signals the attacker can manipulate.

• IP rate limiting: defeated by spreading the attack across thousands of residential proxies, a handful of attempts each.
• CAPTCHA: taxes your legitimate users on every sign-in, and there is a mature market in solving them automatically and by hand.
• WAF and risk scoring: they work in probabilities, so you choose between false positives that block real customers and a threshold that lets the attack through.
• 2FA: it only engages once the password has been accepted, so the attacker already knows which credentials are valid even without completing the login.

What a per-device certificate changes

With mTLS the server requires the client to present its own certificate during the TLS handshake. Without one, or with one your CA chain did not sign, the connection is never established: your application never sees the request.

Applied to mobile, that means only registered installs of your app can reach the login endpoint. A script, a generic HTTP client or a repackaged copy of your app has no such certificate, and no volume of leaked credentials helps them.

For the legitimate user nothing changes: no box to tick, no extra step. The whole cost lands on the attacker.

What it takes to put in place

• Integrate the SDK into the mobile app so each install obtains and renews its certificate.
• Configure your edge server (usually Nginx) to require a client certificate on the sensitive endpoints.
• Decide which routes require it: normally sign-in and registration, not your public resources.
• Define the revocation procedure for devices you consider compromised.