Your company does not have to lose its own password database for a customer account to be taken over. If someone reuses an email address and password exposed by another service, an attacker may be able to sign in with that pair on your website.
Credential stuffing is the automated use of those previously exposed credentials. For a business with customer logins, the immediate question is what prevents a known password from being enough to access an account.
Credential stuffing is different from guessing passwords
OWASP’s credential stuffing guidance distinguishes testing breached username-and-password pairs from password spraying, which tries a common password across many accounts. The distinction matters: a stuffing attempt can succeed on its first try against a particular account.
Multifactor authentication adds another requirement beyond the password. Review whether it is enforced for the relevant users and sign-in methods. An optional feature protects only the accounts that use it. CAPTCHA and IP-based restrictions can add friction, but neither establishes that a valid password belongs to the person submitting it.
Check the login routes, not just the settings page
List the browser login, mobile sign-in, older authentication endpoints, and any local-password fallback behind single sign-on. Identify which service applies each control. Then verify that the routes still in use follow the intended policy.
For an assessment, ask for a coverage record showing the endpoint, account type, expected challenge, and observed result. This makes an exception visible without assuming that every application has the same authentication design. Retire unused routes through the normal engineering process and confirm they no longer authenticate users.
Rate limits need to preserve legitimate access
Review how failed attempts are counted and what happens when a limit is reached. A restriction based only on source IP can miss activity distributed across addresses. An aggressive account lockout can also let someone deny access to a legitimate customer by deliberately causing failures.
OWASP’s authentication guidance discusses throttling and lockout tradeoffs. Choose controls for the application’s traffic and risk, then verify their behavior with designated accounts. There is no universal request threshold that proves a login is secure.
Screen passwords without collecting more sensitive data
NIST’s password guidance calls for checking newly established or changed passwords against a blocklist of common, expected, or compromised values. That is a useful design reference for reducing known weak choices.
Check how the application performs this comparison and handles credentials during the process. Keep passwords out of analytics, logs, and assessment reports. Password screening complements sign-in protections; a password can become exposed after it was first accepted.
Ask for evidence from a controlled assessment
Use test accounts and synthetic credentials, with agreed request limits and stop conditions. Real breached credential lists and attempts against customer accounts are unnecessary for verifying your own control behavior.
Ask the assessor to record whether the correct challenge appeared, which limits were enforced, and whether the security team received the expected events. Include a normal successful login after the test so the result accounts for customer access as well as blocking.
Recovery deserves its own check: a strong login can be undermined by a weaker route for regaining access. Ceron’s password reset review covers that part of the account lifecycle. To include login protection in your next assessment, discuss your authentication scope with Ceron.
