Skip to main content
Home/DPDP Dictionary/Credential Stuffing
DPDP Dictionary · Security & breach

Credential Stuffing

Using leaked username-password pairs from one site to break into accounts on another.

Security & breachReviewed October 2026
In simple words

Credential stuffing is an automated attack that tries leaked email-and-password pairs on other websites, hoping that people reused the same password and the login works.

Meaning of Credential Stuffing

Because many people reuse passwords, attackers try leaked combinations at scale. Rate limiting, breach-password checks and multi-factor authentication help.

Credential stuffing relies on a simple habit: people reuse passwords. When one website is breached, the stolen email and password pairs circulate in criminal markets. Attackers load these lists into automated tools, often spread across thousands of IP addresses, and try them against banking apps, shopping sites, streaming services and employee portals. A small percentage of attempts succeed, and at scale that is enough to take over thousands of accounts without any weakness in the target system itself.

Credential stuffing differs from brute force, where an attacker guesses passwords, and from phishing, where a person is tricked. Here the passwords are genuine and the login looks valid. This makes it harder to spot. The pattern is usually many failed logins from many sources, a spike in password-reset requests, and logins from unusual devices or places soon after a success. The attack hits both customers and staff, since employees reuse passwords between personal and work accounts.

Under the DPDP Act, an account takeover that exposes a person's personal data, such as addresses, order history, wallet balances or identity documents, is likely to be an unauthorised access that meets the definition of a personal data breach in Section 2(u). A fiduciary can argue that the weakness lay in the user's password habits, but Section 8(5) still expects reasonable safeguards to prevent a breach, and Rule 6 lists access control and monitoring. Whether a particular incident is reportable needs a case-by-case legal view.

Banks and payment firms in India already work under RBI authentication rules, which reduce the damage, but retailers, edtech platforms, gaming sites and healthcare portals often have only a password. As the DPDP obligations apply from 13 May 2027, organisations with consumer accounts should check that login defences are proportionate to the personal data behind them.

Examples of Credential Stuffing

Quick example

Attackers take a leaked list of emails and passwords and try them on a shopping app, taking over thousands of accounts.

Online retailer

A retailer sees 400,000 failed logins in an hour from many addresses. Rate limiting blocks most, but 800 accounts are accessed. It forces resets, emails affected customers with advice, assesses the exposed data and records the event in its breach register.

Gaming platform

A mobile game finds that stolen player accounts are being sold. It adds new-device verification, checks passwords against breached lists and offers MFA, with in-game rewards for turning it on, which raises adoption quickly.

School

A school's parent portal has no lockout, and an attacker opens several accounts using reused passwords. The school adds lockouts, email alerts on new logins and a requirement that staff accounts use MFA, then tells the parents concerned.

Why Credential Stuffing matters

Account takeover leads directly to harm: stolen loyalty points, fraudulent orders, misuse of saved cards or addresses, access to private messages and health records. Customers blame the platform, not the original leak, and support teams are flooded. The Schedule to the Act allows penalties of up to ₹250 crore for failing to take reasonable security safeguards, and up to ₹200 crore for failing to notify a breach.

The business impact also includes fraud losses, refund costs, higher support volumes and churn. Because attacks are cheap and automated, any popular consumer service will be tested sooner or later. The question the Board is likely to ask is not whether it happened, but whether you had sensible controls and responded promptly when it did.

How it works in practice

  1. 1Offer and encourage multi-factor authentication. Make it mandatory for administrators and staff and strongly encouraged, or required for sensitive actions, for customers. Prefer app-based or passkey options over SMS codes where possible.
  2. 2Add rate limiting and bot detection. Throttle repeated logins per account, address and device, use CAPTCHAs or risk-based challenges when behaviour looks automated, and block known malicious sources.
  3. 3Check new and existing passwords against lists of known breached passwords, and force a reset when a match is found. Follow current guidance that favours length and screening over complex-looking composition rules.
  4. 4Monitor and alert. Track login failure ratios, password-reset spikes and impossible travel, notify users of new-device logins, and keep authentication logs for at least a year as Rule 6 expects.
  5. 5Prepare the response. When a wave hits, lock affected accounts, force resets, tell customers plainly what happened and what to do, assess the data exposed, and decide on intimation to the Board under Rule 7.

Where it appears in the DPDP Act and Rules

Common mistakes to avoid

Relying on password complexity rules alone. Complex passwords that are reused are still stuffable, so screen against breached lists and add a second factor.

Blaming users and doing nothing. Section 8(5) places the duty to take reasonable safeguards on the fiduciary, so build defences that assume password reuse.

Counting only successful logins. Failed-login patterns are the early warning, so monitor them.

Sending vague notices after takeovers. Tell customers which data could be seen and exactly what to do next.

Compliance tips

  • Send a security notification on every new-device login and password change, with a one-tap "this wasn't me" link.

  • Test your login endpoint with a controlled simulation, so you know at what volume your defences trigger.

  • Ask customers, through short in-app tips, not to reuse passwords, and suggest a password manager.

Common questions about Credential Stuffing

Is credential stuffing a data breach under the DPDP Act?

It can be. If attackers use valid credentials to access accounts and view or alter personal data, that is likely unauthorised access under Section 2(u). Whether you must notify depends on the facts, so assess each incident and keep a record of the decision.

What is the difference between credential stuffing and brute force?

Brute force guesses passwords systematically. Credential stuffing uses real username and password pairs leaked elsewhere and relies on reuse. It succeeds with far fewer attempts per account and looks like normal logins, so it needs different detection.

What is the best defence against credential stuffing?

No single control is enough, but multi-factor authentication is the strongest, combined with rate limiting, bot detection, breached-password screening and alerts on suspicious logins. Rule 6 expects access control and monitoring, which these measures provide.

Industry guides where this matters

More in Security & breach

General information, not legal advice. Check the Act, the Rules and any notifications for your situation.

Keep learning