Login defences: stuffing, spraying, enumeration

In one made-up hour at a site with 20,000 accounts, 6,000 sign-in attempts arrived with email and password pairs from another site’s breach. They opened 43 accounts, and not one account failed more than once, so a lock after five failures would never have fired.

Defending sign-in starts with the shape of that traffic: how many accounts it names, how often each one, from how many sources, and how many of the names have no account here at all. You will tell the common shapes apart in a log, place throttles where each one bites, give every outcome of sign-in, sign-up and reset the same answer, check passwords against breached ones without sending them anywhere, and decide where a second factor, a CAPTCHA and device recognition belong.

Stuffing, spraying and one-account guessing leave different shapes in a log

OWASP’s Credential Stuffing Prevention Cheat Sheet tells three kinds of automated guessing apart by what they try. Credential stuffingcredential stuffing: Trying username and password pairs that leaked from another site's breach against your sign-in, betting that people reuse passwords. Each account is tried once or twice, from many sources, and many of the names have no account on your site. tests username and password pairs taken from the breach of another site. Password sprayingpassword spraying: Trying one or a few common passwords against many accounts, slowly, so that no single account sees enough failures to trip a per-account limit. Screening common passwords at sign-up removes what it looks for. tests one weak password against a large number of accounts. Brute force tests many passwords against one account. The Top 10’s A07 adds a hybrid that tries variations of leaked passwords, and its example is a season with the year moved on by one, Winter2025 becoming Winter2026.

The hour below is a model, and every rate in it is the model’s own assumption. 3,000 people sign in, and three automated senders run beside them. A real log has no column that says who sent an attempt, so the program uses its own labels to show the shape each sender leaves:

// The shape each sender leaves in the hour's log: how many names it tries, how often per name and per source, and
// how many of its names have no account here. The log itself has no "sender" column: the model labels it.
import { buildHour } from './traffic.mjs';

const hour = buildHour();
const senders = ['people', 'pairs', 'spray', 'one-account'];
const most = (map) => Math.max(...map.values());
const rows = senders.map((who) => {
  const mine = hour.filter((a) => a.origin === who);
  const perAccount = new Map();
  const perSource = new Map();
  for (const a of mine) {
    if (a.account !== null) perAccount.set(a.account, (perAccount.get(a.account) ?? 0) + 1);
    perSource.set(a.source, (perSource.get(a.source) ?? 0) + 1);
  }
  const unknown = mine.filter((a) => a.account === null).length;
  return [who, mine.length, perAccount.size, `${Math.round((100 * unknown) / mine.length)} %`, most(perAccount), perSource.size, most(perSource), mine.filter((a) => a.password === 'right').length];
});
const head = ['sender', 'tries', 'accounts', 'no account', 'most/account', 'sources', 'most/source', 'right password'];
const widths = head.map((h, i) => Math.max(h.length, ...rows.map((r) => String(r[i]).length)));
const line = (cells) => cells.map((c, i) => (i === 0 ? String(c).padEnd(widths[i]) : String(c).padStart(widths[i]))).join('  ');
console.log(line(head));
for (const r of rows) console.log(line(r));

sender       tries  accounts  no account  most/account  sources  most/source  right password
people        3265      3001         1 %             2     2701            4            3001
pairs         6000      3253        46 %             1     1500            4              43
spray         6000      2000         0 %             3       10          600              13
one-account    400         1         0 %           400        1          400               1

// One made-up hour of sign-in attempts at a site with 20,000 accounts. Every number below is this model's own
// assumption, chosen to show the shapes clearly; none is a measurement of a real site.

/** A seeded random source (mulberry32), so every run builds the same hour. */
export function seeded(seed) {
  let a = seed >>> 0;
  return () => {
    a = (a + 0x6d2b79f5) >>> 0;
    let t = a;
    t = Math.imul(t ^ (t >>> 15), t | 1);
    t ^= t + Math.imul(t ^ (t >>> 7), t | 61);
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}

export const ACCOUNTS = 20000;
const COMMON = ['common-1', 'common-2', 'common-3']; // three passwords from a list of common ones

/**
 * The hour as a list of attempts in time order: { t, account, source, knownDevice, password, origin }.
 * account is null when the name has no account here; origin says who sent it (the model's label, never in a log).
 * screened: true when the site refused common passwords at registration, so no account uses one.
 */
export function buildHour({ seed = 12, screened = false } = {}) {
  const r = seeded(seed);
  const pick = (n) => Math.floor(r() * n);
  const attempts = [];
  // Passwords that matter here: 1 account in 170 uses a common password (none when the site screened them at
  // registration), and the owners of 1 in 100 of the accounts on the outside list use the same password here as there.
  const common = new Map();
  if (!screened) for (let a = 13; a < ACCOUNTS; a += 170) common.set(a, COMMON[Math.floor(a / 170) % 3]);
  // 3,000 people sign in: 8 in 100 mistype the password once, 1 in 100 first type a name with no account here.
  for (let i = 0; i < 3000; i++) {
    const account = 100 + i * 6;
    const source = `home-${i % 2700}`; // 300 people share an address with someone else
    const knownDevice = r() >= 0.05;
    let t = pick(3600);
    if (r() < 0.01) attempts.push({ t: t++, account: null, source, knownDevice, password: 'wrong', origin: 'people' });
    if (r() < 0.08) attempts.push({ t: (t += 2), account, source, knownDevice, password: 'wrong', origin: 'people' });
    attempts.push({ t: Math.min(3599, t + 5 + pick(15)), account, source, knownDevice, password: 'right', origin: 'people' });
  }
  // The owner of account 77 signs in at minute 40, from home, on a device the site knows.
  attempts.push({ t: 2400, account: 77, source: 'home-owner-77', knownDevice: true, password: 'right', origin: 'people' });
  // Pairs from another site's breach: 6,000 names, 45 in 100 with no account here, one try each, between minute 10
  // and minute 50, from 1,500 sources.
  const used = new Set();
  for (let k = 0; k < 6000; k++) {
    let account = null;
    if (r() >= 0.45) {
      do account = pick(ACCOUNTS); while (used.has(account));
      used.add(account);
    }
    const reused = account !== null && r() < 0.01;
    attempts.push({ t: 600 + pick(2400), account, source: `pairs-${k % 1500}`, knownDevice: false, password: reused ? 'right' : 'wrong', origin: 'pairs' });
  }
  // Spraying: three common passwords against 2,000 existing accounts, a quarter of an hour apart, from 10 sources.
  const sprayed = new Set();
  for (let k = 0; k < 2000; k++) {
    let account;
    do account = pick(ACCOUNTS); while (sprayed.has(account));
    sprayed.add(account);
    const start = pick(900);
    COMMON.forEach((pw, j) => {
      attempts.push({ t: start + j * 900 + pick(600), account, source: `spray-${k % 10}`, knownDevice: false, password: common.get(account) === pw ? 'right' : 'wrong', origin: 'spray' });
    });
  }
  // One account, 400 guesses from one source, one every 9 seconds; guess 300 is that account's password.
  for (let k = 0; k < 400; k++) {
    attempts.push({ t: k * 9, account: 77, source: 'one-source', knownDevice: false, password: k === 299 ? 'right' : 'wrong', origin: 'one-account' });
  }
  return attempts.sort((x, y) => x.t - y.t);
}

Read the table row by row. The pairs named 3,253 existing accounts once each, and 46 % of their names had no account here, because the list was made on another site. The spray tried 2,000 accounts three times each, a quarter of an hour apart, from only 10 sources, so each source sent 600 attempts. The one-account guessing made 400 tries on account 77 from a single source. People made 3,265 attempts on 3,001 accounts, at most 2 per account, and 1 % of their names had no account, which is what typing mistakes look like.

The shapes decide what a defence has to count:

Each throttle sees one shape, and a lock on the account alone shuts out owners

A throttle counts something, and it stops only the traffic that drives its count up. The program replays the same hour against seven sets of controls, one more control on each row. A delay doubles after each failure, from 1 second up to 60, and a source limit refuses a source that failed 20 times in the last 10 minutes:

// The same hour against seven sets of sign-in controls. "Checked" counts password checks the site ran; "opened"
// counts accounts that a sender other than their owner signed in to; the last two columns are what people paid.
import { buildHour } from './traffic.mjs';

function run({ delay = null, sourceLimit = false, screened = false, stepUp = false, secondFactor = false }) {
  const hour = buildHour({ screened });
  const fails = new Map(); // delay key -> { n, last }
  const sourceFails = new Map(); // source -> failure times in the last 10 minutes
  const unknownWindow = []; // [t, namedNoAccount] for the last 5 minutes
  let unknownInWindow = 0;
  let stepUpUntil = -1;
  const opened = { pairs: new Set(), spray: new Set(), 'one-account': new Set() };
  const refused = new Set();
  const challenged = new Set();
  let checked = 0;
  hour.forEach((a, i) => {
    const person = a.origin === 'people' ? `${a.account}|${a.source}` : null;
    // The site-wide share of attempts that name no account, over the last 5 minutes.
    unknownWindow.push([a.t, a.account === null]);
    if (a.account === null) unknownInWindow++;
    while (unknownWindow[0][0] <= a.t - 300) if (unknownWindow.shift()[1]) unknownInWindow--;
    const share = unknownInWindow / unknownWindow.length;
    if (stepUp && unknownWindow.length >= 50 && share > 0.1) stepUpUntil = a.t + 900;
    const key = delay === 'account' ? `${a.account ?? `none-${i}`}` : `${a.account ?? `none-${i}`}|${a.source}`;
    const f = fails.get(key);
    if (delay && f && a.t < f.last + Math.min(2 ** (f.n - 1), 60)) {
      if (person) refused.add(person);
      return; // 429: refused before any password check
    }
    const recent = (sourceFails.get(a.source) ?? []).filter((t) => t > a.t - 600);
    sourceFails.set(a.source, recent);
    if (sourceLimit && recent.length >= 20) {
      if (person) refused.add(person);
      return;
    }
    checked++;
    if (a.password !== 'right') {
      fails.set(key, { n: (f?.n ?? 0) + 1, last: a.t });
      recent.push(a.t);
      return;
    }
    fails.delete(key);
    const needsCode = secondFactor || (a.t <= stepUpUntil && !a.knownDevice);
    if (person) {
      if (needsCode) challenged.add(person);
      return;
    }
    if (!needsCode) opened[a.origin].add(a.account);
  });
  return [checked, opened.pairs.size, opened.spray.size, opened['one-account'].size, refused.size, challenged.size];
}

const rows = [
  ['no controls', {}],
  ['delay per account', { delay: 'account' }],
  ['delay per account+source', { delay: 'pair' }],
  ['+ limit per source', { delay: 'pair', sourceLimit: true }],
  ['+ common passwords refused', { delay: 'pair', sourceLimit: true, screened: true }],
  ['+ code on spike, new device', { delay: 'pair', sourceLimit: true, screened: true, stepUp: true }],
  ['+ second factor for all', { delay: 'pair', sourceLimit: true, screened: true, stepUp: true, secondFactor: true }],
].map(([name, opts]) => [name, ...run(opts)]);
const head = ['controls', 'checked', 'opened: pairs', 'spray', 'one account', 'people refused', 'people asked for a code'];
const widths = head.map((h, i) => Math.max(h.length, ...rows.map((r) => String(r[i]).length)));
const line = (cells) => cells.map((c, i) => (i === 0 ? String(c).padEnd(widths[i]) : String(c).padStart(widths[i]))).join('  ');
console.log(line(head));
for (const r of rows) console.log(line(r));

controls                     checked  opened: pairs  spray  one account  people refused  people asked for a code
no controls                    15665             43     13            1               0                        0
delay per account              15317             43     13            0               7                        0
delay per account+source       15327             43     13            0               0                        0
+ limit per source             10395             43      4            0               0                        0
+ common passwords refused     10391             43      0            0               0                        0
+ code on spike, new device    10391              1      0            0               0                      115
+ second factor for all        10391              0      0            0               0                     3001

With no controls, 57 accounts were opened: 43 by the pairs, 13 by the spray and 1 by the guessing on account 77. A delay keyed by the account alone stopped the 400 guesses, and it also refused 7 people, owners of accounts on which the other senders were failing at the same time. Keyed by account and source together, the same delay stopped the guessing and refused nobody, because each owner signs in from a source of their own.

The source limit cut the spray from 13 accounts to 4, because the spray came from 10 busy sources. It did nothing to the pairs, which sent 4 attempts per source. Refusing common passwords at sign-up removed the spray’s last 4, since no account was left with one of the three passwords it tried. The pairs stayed at 43 until the last two rows. A code sent to unknown devices while names with no account spiked brought them to 1, at the cost of a code for 115 people who signed in from a new device during the spike. A second factor on every account brought every sender to 0, and asked all 3,001 people for it.

NIST SP 800-63B-4 sets the upper bound for counting by account: no more than 100 consecutive failed attempts on one account. It also allows ways to lower the chance that the real owner is shut out, such as a bot-detection challenge, waits that grow as the count rises, and risk-based techniques. The Top 10 puts the trade-off in one line: limit or increasingly delay failed sign-ins, but do not create a denial of service.

One answer for every outcome, in sign-in, sign-up and reset

A sign-in form that says “Wrong password” for one account and “No account with that email” for another tells a stranger which addresses have accounts, which is user enumerationuser enumeration: Finding out which accounts exist from differences in a service's answers, such as the words, the status code or the response time. A login or reset form should give the same answer and do the same work for every name. More in “Passwords and secret tokens for web apps”. The lesson on passwords fixed the sign-in form with one message and the same hashing work for every name. Sign-up and reset give accounts away just as easily: “This email is already registered” is the same answer in other words. ASVS 5.0.0 requirement 6.3.8 asks, at level 3, that valid users cannot be deduced from failed sign-ins through error messages, status codes or timing, and that sign-up and recovery are protected the same way.

The program sends each flow two requests, one for an address with an account and one for an address without, to a weak and a fixed version, and compares everything a stranger can see. The status, the redirect, the cookie and the body are in the answer; the time is modelled by “work”, the number of password hashes, which is what makes a request slow:

// Sign-in, sign-up and password reset, each in a weak and a fixed version, and a check that asks every flow about an
// address that has an account and one that has none. A stranger sees the status, the redirect, the cookie, the body
// and the time; "work" counts password hashes, the step that sets the time. The mail goes to the address, not to them.
const accounts = new Map([['asha@example.com', 'hash-of-asha']]);
const mail = [];

function weakApp() {
  return {
    signIn(email, work) {
      if (!accounts.has(email)) return { status: 404, body: 'No account with that email' };
      work.hashes++;
      return { status: 401, body: 'Wrong password' };
    },
    signUp(email, work) {
      if (accounts.has(email)) return { status: 409, body: 'This email is already registered' };
      work.hashes++;
      return { status: 302, location: '/welcome', cookie: true, body: '' };
    },
    reset(email) {
      if (!accounts.has(email)) return { status: 404, body: 'No account found for that email' };
      mail.push([email, 'reset link']);
      return { status: 200, body: 'We sent a reset link to your email' };
    },
  };
}

const jobs = []; // the fixed app's work after the response, done by a queue

function fixedApp() {
  return {
    signIn(email, work) {
      work.hashes++; // the real hash, or a dummy hash with the same settings for a name with no account
      return { status: 401, body: 'Invalid email or password' };
    },
    signUp(email, work) {
      work.hashes++; // hash the new password either way; the account starts only when the link is used
      jobs.push(() => mail.push([email, accounts.has(email) ? 'you already have an account: sign in or reset' : 'finish signing up']));
      return { status: 202, body: 'Check your email to finish signing up' };
    },
    reset(email) {
      jobs.push(() => accounts.has(email) && mail.push([email, 'reset link']));
      return { status: 202, body: 'If that address has an account, we sent it a reset link' };
    },
  };
}

/** What a stranger can tell apart: everything in the answer, and the work as a stand-in for the time. */
function seen(app, flow, email) {
  const work = { hashes: 0 };
  const r = app[flow](email, work);
  return { status: r.status, location: r.location ?? '-', cookie: r.cookie ? 'set' : '-', body: r.body, work: work.hashes };
}

for (const [name, app] of [['weak', weakApp()], ['fixed', fixedApp()]]) {
  mail.length = 0;
  let differ = 0;
  for (const flow of ['signIn', 'signUp', 'reset']) {
    const a = seen(app, flow, 'asha@example.com');
    const b = seen(app, flow, 'nobody@example.com');
    const fields = Object.keys(a).filter((k) => a[k] !== b[k]);
    if (fields.length) differ++;
    console.log(`${name.padEnd(5)}  ${flow.padEnd(6)}  ${fields.length ? `tells them apart by ${fields.join(', ')}` : `same answer: ${a.status} "${a.body}"`}`);
  }
  console.log(`${name.padEnd(5)}  check ${differ ? 'FAILS' : 'passes'}: ${differ} of 3 flows answer differently\n`);
}
// The queue runs later. Only the owner of each address reads what the fixed flows sent there.
for (const job of jobs) job();
for (const to of ['asha@example.com', 'nobody@example.com']) {
  console.log(`mail to ${to}: ${mail.filter(([e]) => e === to).map(([, m]) => m).join('; ')}`);
}

weak   signIn  tells them apart by status, body, work
weak   signUp  tells them apart by status, location, cookie, body, work
weak   reset   tells them apart by status, body
weak   check FAILS: 3 of 3 flows answer differently

fixed  signIn  same answer: 401 "Invalid email or password"
fixed  signUp  same answer: 202 "Check your email to finish signing up"
fixed  reset   same answer: 202 "If that address has an account, we sent it a reset link"
fixed  check passes: 0 of 3 flows answer differently

mail to asha@example.com: you already have an account: sign in or reset; reset link
mail to nobody@example.com: finish signing up

The weak flows fail the check in all three places: sign-in by status, words and work, sign-up by five fields at once, and reset by status and words. The fixed flows give one answer each, and they move the difference to where only the owner of the address can read it, the inbox. That follows OWASP’s Authentication Cheat Sheet, whose model answer to a sign-up is the same for every address: a link has been emailed to the address provided. For an address that already has an account, the fixed flow mails a notice in place of the link. Step through the fixed sign-up for both addresses:

Keep the check: the weak flows make it fail and the fixed ones make it pass, so it belongs in the test suite for every flow that takes an address, the API included. A new flow, or a quick fix to an old one, then cannot bring the difference back.

Check new passwords against breached ones without sending them

A password that already appears in a breach is the first one a list of pairs will try. NIST SP 800-63B-4 asks verifiers to compare a new password with a blocklist of common, expected and compromised values. ASVS 5.0.0 asks for a check against at least the 3,000 most common passwords (6.2.4) and, at level 2, against a set of breached passwords (6.2.12), at sign-up and at every change. The Top 10 suggests the 10,000 worst passwords. A reset sets a new password as well, so it gets the same check.

A breach list is too large to ship in every app, and nobody should send a password to another service to ask. The Pwned Passwords range API removes that dilemma with k-anonymityk-anonymity: Asking about a value without naming it: you send a short prefix of its hash that many hashes share, the service answers with all of them, and you compare the rest yourself. The Pwned Passwords range API works this way with five hex characters of a SHA-1.. The app hashes the password with SHA-1 and sends only the first five of the 40 hex characters. The service answers with every suffix that starts with those five, each with its count, and the app compares its own 35 remaining characters with that list. No API key is needed, and with the header Add-Padding: true every answer is padded to between 800 and 1,000 lines, the padding marked with a count of 0, so that its size says nothing about the prefix. The program runs the check on two made-up responses in that format, cut to 15 and 14 lines so that you can read them:

# A breached-password check at sign-up, the way the Pwned Passwords range API works: hash the password with SHA-1,
# send only the first five hex characters, and compare the rest here. The two responses in ranges/ are made-up files
# in the documented format (SUFFIX:COUNT, one per line); the program sends nothing over a network.
import hashlib
from pathlib import Path


def range_response(prefix):
    """Stands in for GET https://api.pwnedpasswords.com/range/<prefix> with the Add-Padding header."""
    return (Path("ranges") / f"{prefix}.txt").read_text()


def weak_count(password):
    digest = hashlib.sha1(password.encode("utf-8")).hexdigest()  # lower case
    for line in range_response(digest[:5].upper()).splitlines():
        suffix, _, count = line.partition(":")
        if suffix == digest[5:]:  # the service sends upper case, so this never matches
            return int(count)
    return 0


def breach_count(password):
    digest = hashlib.sha1(password.encode("utf-8")).hexdigest().upper()
    prefix, suffix = digest[:5], digest[5:]
    lines = range_response(prefix).splitlines()
    padding = sum(1 for line in lines if line.endswith(":0"))
    print(f"  sent: {prefix} (5 of 40 hex characters); kept here: {suffix[:5]}...{suffix[-4:]}")
    print(f"  answer: {len(lines)} lines, {padding} of them padding with a count of 0")
    for line in lines:
        candidate, _, count = line.partition(":")
        if candidate.strip().upper() == suffix and int(count) > 0:
            return int(count)
    return 0


for password in ["Rain-on-the-roof-1", "a-sentence-nobody-has-typed-before"]:
    print(password)
    found = breach_count(password)
    print(f"  weak check: {'found' if weak_count(password) else 'not found'}")
    verdict = f"found {found:,} times: refuse it and ask for another" if found else "not found: accept it"
    print(f"  fixed check: {verdict}")

Rain-on-the-roof-1
  sent: 4513C (5 of 40 hex characters); kept here: 6B0FD...BCC7
  answer: 15 lines, 5 of them padding with a count of 0
  weak check: not found
  fixed check: found 2,047 times: refuse it and ask for another
a-sentence-nobody-has-typed-before
  sent: 04012 (5 of 40 hex characters); kept here: 04719...5BE4
  answer: 14 lines, 5 of them padding with a count of 0
  weak check: not found
  fixed check: not found: accept it

18B40AF47F492D549DC46C03C21BB00FA9E:14
1C50884ADFFA01738A06E8B26034A7E6592:0
2CF3DFC8DF07413DF4F73EF8C9FCD698014:120
32C893BFF37BEB222F9875ADAAFCA56E7BB:0
3A37DFE702393E0FA6C8BBC2A299E490BBE:37
3B8C9B1D09A939DA0A61353314B90D4BDCC:5
3FE546DAE72C16511E6F046455C8DD2C95B:3
531B53A829A58820D8D01370933BAE1CA6E:37
6B0FDF4AE8A26B1972511F7D0ED6911BCC7:2047
8EFD9E5AFE3836702EAD50B5B6386984383:37
9165999B4C60FDB505A45030B2B964743AF:0
BBEEF965D4F0BD1529B8430691CC5324CA8:0
D7450C847008FD8A42518AA107F174CB78A:5
DC64E4D8A3A8E8487A4389ECC0ADA3F6DBA:0
FB68FEFD19AE3E8E5DF28FB36D4E020E267:2

2E55756AC85E20B247F4A5F340C2FDAB208:5
3C795900A5E37F5F324094D80E94C0E337A:0
3E1BE16F1925286091F8257F1B7CE2710DC:961
403C2580123A49F7AE7C7AD1F75E63FCF0F:5
532B74EE3D420ED2EF1EFB31D5D287D3B50:0
65FCF5D6B02336C3EB3D7A9032A4ED336FA:0
7591695D4ECF191A9D79BBC70DDCB7CB037:0
9548B4E55154DF097B2ED4A41F013B8A056:2
9F2AFAAB5258C360E76D468F4ABC6444411:8
C0FE8BF4347BEC1A82EEB3891212E3CEF04:14
C1E497A8D0B53B625EC33DC0761858B2851:5
D4308D157FAABAF8FA81F40FB8E6B8C961D:2
DD6577F6B5DDEB69EF26632B5356D6D0489:14
E2C8EE98EDF9A530669C7A537C4AC69C8BE:0

The first password is in the made-up response 2,047 times, so sign-up refuses it and asks for another; the second is not in its response, so sign-up accepts it. The weak check never finds anything, because hexdigest() returns lower case and the service sends upper case, and a check that never fires looks exactly like a list with no matches. The fixed check compares in one case, skips the padding lines and needs a count above 0. Step through one lookup:

The service’s documentation adds one caution for forms that check as the person types: a search on every character can give a third party who sees the requests enough to work out the password. Wait until the field is complete, and make the call from your server.

Rules that read the whole log catch what one attempt cannot show

Throttles decide one attempt at a time. Some shapes appear only across many attempts, so the next layer is a set of rules that read the log. They need a few fields per attempt: the time, the account named or the fact that none exists, the source, whether the device was known and the result. They never need the password: ASVS 5.0.0 asks, at level 2, that every authentication operation is logged, success or failure (16.3.1), and that credentials are never written to a log (16.2.5). The program runs four rules over the hour of the first section and scores each one with the model’s labels:

// Four rules read the hour's log the next morning. The log has the time, the account named (or none), the source,
// whether the device was known and the result, never the password. The model's labels score each rule.
import { buildHour } from './traffic.mjs';

const hour = buildHour();
const failed = (a) => a.password !== 'right';

// Rule 1: a source that fails on 10 or more different accounts within 10 minutes; its attempts are flagged from then
// until 10 minutes after the rule last fired, successes included.
function wideSources() {
  const out = new Set();
  const bySource = new Map();
  const firedAt = new Map();
  hour.forEach((a, i) => {
    const list = (bySource.get(a.source) ?? []).filter(([t]) => t > a.t - 600);
    if (failed(a)) list.push([a.t, a.account ?? `none-${i}`, i]);
    bySource.set(a.source, list);
    if (new Set(list.map((x) => x[1])).size >= 10) {
      firedAt.set(a.source, a.t);
      for (const x of list) out.add(x[2]);
    }
    if (a.t <= (firedAt.get(a.source) ?? -Infinity) + 600) out.add(i);
  });
  return out;
}
// Rule 2: a 5-minute stretch in which more than 10 % of attempts name no account; flags its unknown devices.
function noAccountSpike() {
  const out = new Set();
  for (let start = 0; start < 3600; start += 300) {
    const inside = hour.map((a, i) => [a, i]).filter(([a]) => a.t >= start && a.t < start + 300);
    const share = inside.filter(([a]) => a.account === null).length / inside.length;
    if (share > 0.1) for (const [a, i] of inside) if (!a.knownDevice) out.add(i);
  }
  return out;
}
// Rule 3: a right password on an account that failed 5 or more times in the hour before it.
function successAfterFailures() {
  const out = new Set();
  const fails = new Map();
  hour.forEach((a, i) => {
    if (a.account === null) return;
    const recent = (fails.get(a.account) ?? []).filter((t) => t > a.t - 3600);
    if (failed(a)) recent.push(a.t);
    else if (recent.length >= 5) out.add(i);
    fails.set(a.account, recent);
  });
  return out;
}
// Rule 4: a right password from a device the site does not know. This one sends the owner a notice.
const newDeviceSuccess = () => new Set(hour.flatMap((a, i) => (!failed(a) && !a.knownDevice ? [i] : [])));

const opened = hour.flatMap((a, i) => (a.origin !== 'people' && !failed(a) ? [i] : []));
const count = (set, who) => hour.filter((a, i) => set.has(i) && a.origin === who).length;
const total = (who) => hour.filter((a) => a.origin === who).length;
const pct = (n, d) => `${Math.round((100 * n) / d)} %`;
const rules = [
  ['1 source, 10+ accounts', wideSources()],
  ['2 no-account spike', noAccountSpike()],
  ['3 success after 5 fails', successAfterFailures()],
  ['4 success, new device', newDeviceSuccess()],
];
const head = ['rule', 'flagged', 'precision', 'pairs', 'spray', 'one account', 'people', `opened (of ${opened.length})`];
const rows = rules.map(([name, set]) => {
  const machine = set.size - count(set, 'people');
  return [name, set.size, pct(machine, set.size), pct(count(set, 'pairs'), total('pairs')), pct(count(set, 'spray'), total('spray')), pct(count(set, 'one-account'), total('one-account')), count(set, 'people'), opened.filter((i) => set.has(i)).length];
});
const widths = head.map((h, i) => Math.max(h.length, ...rows.map((r) => String(r[i]).length)));
const line = (cells) => cells.map((c, i) => (i === 0 ? String(c).padEnd(widths[i]) : String(c).padStart(widths[i]))).join('  ');
console.log(line(head));
for (const r of rows) console.log(line(r));
const any = new Set(rules.slice(0, 3).flatMap(([, s]) => [...s]));
console.log(`\nrules 1 to 3 together: ${opened.filter((i) => any.has(i)).length} of ${opened.length} opened accounts, ${count(any, 'people')} people's attempts flagged`);

rule                     flagged  precision  pairs  spray  one account  people  opened (of 57)
1 source, 10+ accounts      6000      100 %    0 %  100 %          0 %       0              13
2 no-account spike         11545       99 %  100 %   86 %         67 %     108              56
3 success after 5 fails        4       25 %    0 %    0 %          0 %       3               1
4 success, new device        199       29 %    1 %    0 %          0 %     142              57

rules 1 to 3 together: 57 of 57 opened accounts, 111 people's attempts flagged

Rule 1 flagged every spray attempt and nothing else, because no person fails on 10 different accounts in 10 minutes; it caught the spray’s 13 opened accounts. Rule 2, the share of names with no account, caught the pairs wave and 56 of the 57 opened accounts. It flagged a whole stretch of the hour, 11,545 attempts with 108 of them from people, so it is a reason to step up, not to block. Rule 3 found the one account opened after 400 guesses, along with 3 owners who signed in after others had failed on their accounts. Together, rules 1 to 3 caught all 57.

Rule 4 is different: a right password from a device the site does not know. It caught all 57 accounts with a precision of 29 %, because 142 people also signed in from new devices. That is too many for a block and exactly right for a notice: ASVS 6.3.5 asks, at level 3, that users hear of suspicious sign-in attempts, and 6.3.7 that they hear of every change to their credentials. OWASP’s Credential Stuffing Prevention Cheat Sheet adds the most telling event to report: a correct password followed by a failed second factor.

Where a second factor, a CAPTCHA and device recognition belong

Every control so far fits into one sign-in flow, and the order matters: refuse what the throttles refuse before spending a hash on it, give every name the same work, read the risk signals, and only then decide whether to ask for more. Step through the flow:

A second factor is the strongest step. OWASP’s Credential Stuffing Prevention Cheat Sheet calls it by far the best defence against most password-related attacks, and adds that it can be required only in some situations, such as a new device or a risky action. The model showed both versions: every account at 0, with every person asked, or 1 account opened with 115 people asked, because the risk signal arrived a few minutes into the wave. Passkeys and the other factors, and how to recover from losing them, are the next lesson.

A CAPTCHA is a defence-in-depth step and not a defence. OWASP’s Credential Stuffing Prevention Cheat Sheet says that it may slow automation, that tools and services exist that break many of them, and that it can be shown only when a sign-in already looks suspicious. Under WCAG 2.2 success criterion 3.3.8, a step of authentication may demand a cognitive function test, such as a puzzle, only if it also gives people another method or a mechanism that does the work for them; on their own, only tests that ask a person to recognise objects, or non-text content they gave the site, are allowed. A CAPTCHA that asks for typed characters at sign-in therefore needs another way through.

Device recognitionTelling a device that has signed in before from a new one, by a long-lived cookie the site set or by traits of the browser. It is a signal about risk and proves nothing about the person. reads a long-lived cookie or the traits of the browser. OWASP’s Authentication Cheat Sheet treats such signals as risk signals and never as substitutes for authentication, and the Credential Stuffing Prevention Cheat Sheet warns that a client can fake its traits. Two last rules belong to every flow: ship no default accounts, which ASVS 6.3.2 asks at level 1, and keep every sign-in route, the mobile API included, behind the same controls. The table below decides between the extra steps for your own sign-in:

Practise: a throttle and a breach check you can trust

Build two parts of a hardened sign-in in JavaScript: the throttle of the second section, keyed by account and source with a limit per source, and the range check of the fourth. The sample tests include the boundaries, the owner signing in from home while someone else fails on their account, and a response with padding lines:

/** A sign-in throttle: a delay for each account and source, and a limit of failures for each source. */
export function createThrottle() {
  return {
    allowed(account, source, now) {
      return true;
    },
    failed(account, source, now) {},
    succeeded(account, source) {},
  };
}

import { test, assert } from 'mysmartcopilot:test';
import { createThrottle } from './throttle.mjs';

test('a first attempt is allowed', () => {
  const t = createThrottle();
  assert.equal(t.allowed('asha', 'home', 0), true);
});

test('the wait doubles from 1 second', () => {
  const t = createThrottle();
  t.failed('asha', 'x', 100);
  assert.equal(t.allowed('asha', 'x', 100), false, 'no attempt at once after a failure');
  assert.equal(t.allowed('asha', 'x', 101), true, '1 second after the first failure');
  t.failed('asha', 'x', 101);
  assert.equal(t.allowed('asha', 'x', 102), false, 'the second wait is 2 seconds');
  assert.equal(t.allowed('asha', 'x', 103), true);
});

test('the wait stops at 60 seconds', () => {
  const t = createThrottle();
  let now = 0;
  for (let n = 1; n <= 8; n++) {
    while (!t.allowed('asha', 'x', now)) now++;
    t.failed('asha', 'x', now);
  }
  const last = now;
  assert.equal(t.allowed('asha', 'x', last + 59), false);
  assert.equal(t.allowed('asha', 'x', last + 60), true, 'after eight failures the wait is 60, not 128');
});

test('a success clears the count', () => {
  const t = createThrottle();
  t.failed('asha', 'home', 0);
  assert.equal(t.allowed('asha', 'home', 1), true);
  t.succeeded('asha', 'home');
  assert.equal(t.allowed('asha', 'home', 1), true);
});

test("another source's failures do not delay the owner", () => {
  const t = createThrottle();
  for (let s = 0; s < 6; s++) t.failed('asha', 'x', s * 100);
  assert.equal(t.allowed('asha', 'x', 501), false, 'the busy source waits');
  assert.equal(t.allowed('asha', 'home', 501), true, 'the owner, from home, does not');
});

test('a source with 20 failures in 600 seconds is refused on every account', () => {
  const t = createThrottle();
  for (let i = 0; i < 20; i++) t.failed(`user-${i}`, 'busy', i);
  assert.equal(t.allowed('someone-new', 'busy', 30), false);
  assert.equal(t.allowed('someone-new', 'quiet', 30), true, 'other sources are not affected');
  assert.equal(t.allowed('someone-new', 'busy', 600), true, 'the failure at 0 is no longer within the last 600 seconds');
});

/** How often the password with this SHA-1 appears in the range answer: 0 when it does not. */
export function breachCount(sha1Hex, getRange) {
  const answer = getRange(sha1Hex.slice(0, 5));
  return answer.includes(sha1Hex.slice(5)) ? 1 : 0;
}

/** 'refuse' for a breached password, 'accept' otherwise. */
export function checkNewPassword(sha1Hex, getRange) {
  return 'accept';
}

import { test, assert } from 'mysmartcopilot:test';
import { breachCount, checkNewPassword } from './breach.mjs';

const HASH = '4513C6B0FDF4AE8A26B1972511F7D0ED6911BCC7';
const ANSWER = ['18B40AF47F492D549DC46C03C21BB00FA9E:14', '1C50884ADFFA01738A06E8B26034A7E6592:0', '6B0FDF4AE8A26B1972511F7D0ED6911BCC7:2047', 'FB68FEFD19AE3E8E5DF28FB36D4E020E267:2'].join('\n');

test('only the five upper-case characters are sent, once', () => {
  const asked = [];
  breachCount(HASH.toLowerCase(), (p) => (asked.push(p), ANSWER));
  assert.deepEqual(asked, ['4513C']);
});

test('a lower-case hash still finds its upper-case suffix', () => {
  assert.equal(breachCount(HASH.toLowerCase(), () => ANSWER), 2047);
});

test('a hash that is not in the answer counts 0', () => {
  assert.equal(breachCount('4513C0000000000000000000000000000000000', () => ANSWER), 0);
});

test('a padding line with a count of 0 is not a match', () => {
  assert.equal(breachCount('1C50884ADFFA01738A06E8B26034A7E6592'.padStart(40, '4513C'), () => ANSWER), 0);
});

test('lines may end with \\r\\n', () => {
  assert.equal(breachCount(HASH, () => ANSWER.split('\n').join('\r\n')), 2047);
});

test('the count is read from the matching line', () => {
  assert.equal(breachCount(HASH, () => ANSWER.replace(':2047', ':3')), 3);
});

test('a breached password is refused and another is accepted', () => {
  assert.equal(checkNewPassword(HASH, () => ANSWER), 'refuse');
  assert.equal(checkNewPassword('4513C0000000000000000000000000000000000', () => ANSWER), 'accept');
});

Then check yourself, one question at a time, weakest idea first:

Interview questions

Warm-up: what is credential stuffing, and how is it different from password spraying and brute force?

Credential stuffing tries username and password pairs that leaked from another site, betting that people reuse passwords: each account is tried once or twice, from many sources, and many of the names have no account on your site. Password spraying tries one or a few common passwords against many accounts, slowly, to stay under per-account limits. Brute force tries many passwords against one account. The difference matters because each control sees one shape: per-account delays stop brute force, per-source limits and common-password screening stop most spraying, and pairs spread thin are seen by site-wide signals such as a spike in names with no account. A second factor stops all three when a password is right.

Key takeaways

• Pairs from a breach, spraying and one-account guessing leave different shapes in a log, and each control sees only the shape it counts: pairs never failed twice on one account, and 46 % of their names had no account here.
• Key delays by account and source and add a limit per source: keyed by the account alone, the delay refused 7 owners, and the per-source limit did nothing against pairs spread over 1,500 sources.
• Give sign-in, sign-up and reset the same answer and the same work for every address, move the difference into the inbox, and keep a test that compares the whole answer.
• Check new and reset passwords against breached ones with a range lookup that sends five hex characters, compare in one case and skip the padding.
• Rules over the log catch what single attempts hide; use the noisy ones to step up or to notify, and put a second factor behind them, which brought every sender in the model to 0.