Where the check lives

Before you start

• Requirements

  Each worked system starts from a scoped list of verbs and numbers.

  Open lesson

Why it matters

Password guessing can come from one machine against many accounts or from many machines against one account. A rule on only one dimension leaves the other attack cheap, while a harsh IP lock can block hundreds of people behind the same office NAT. The login flow must slow attempts by both IP and account and define whether a correct password is accepted during lockout.

A login form should slow down password guessing per account and per IP, without locking out a whole office NAT on one shared IP forever.

For POST /login, apply a loose 20-per-minute rule to IP 203.0.113.9 at the gateway and a tighter failure rule to account ana in the login service; require both, reset ana on success, and define correct-password behavior during lockout.

At the gateway, key a loose counter by IP such as 203.0.113.9 before password work begins. Inside the login service, key a tighter failed-attempt counter by account such as ana. The request proceeds only when both checks permit it, covering one-source and distributed guessing shapes.

A denied attempt receives 429, a growing delay, or a TTL-based lock with an explicit duration. Reset ana’s account counter after a successful login so old typos do not accumulate. Keep the IP threshold high enough for a 300-user office NAT; a botnet with thousands of addresses remains outside this defense.