Security
Defending login against credential stuffing and password spraying
How automated login attacks work and the layered controls that stop them: MFA, breached-password checks, rate limits, and enumeration-safe responses.
The short answer
Credential stuffing replays username and password pairs leaked from other sites; password spraying tries a few common passwords against many accounts. The strongest single control is multi-factor authentication. Around it, check new passwords against known-breached lists (NIST SP 800-63B requires this), rate-limit by account and by source, and return identical responses whether or not an account exists.
Sources last reviewed .
Layered controls
- MFA, ideally phishing-resistant — it defeats both attacks outright.
- Breached-password screening at registration and password change (NIST SP 800-63B).
- Rate limiting and progressive delays per account, per IP and per network, tuned so an attacker cannot lock users out at will.
- Generic error messages and consistent response timing to prevent account enumeration.
- Notifying users of new-device sign-ins.
Storing passwords
Store only a salted, slow, memory-hard hash — Argon2id, scrypt or bcrypt — per the OWASP Password Storage Cheat Sheet. A leaked database of such hashes is expensive to crack; a leaked database of fast hashes is not.
In Authreads
How this applies to Authreads
Authreads stores passwords only as a one-way cryptographic digest, never a recoverable password, and per-tenant password rules are Available. See /security for what is stored and for how long.
Authreads is a multi-tenant identity platform in beta. Capability status is maintained on /roadmap as Available, In progress or Planned.
Building on any of this?
Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.