Login watch

1. Open the site, Login watch tab, tick it on.
2. Put in the login paths, one per line.
3. Set which methods count, usually POST.
4. Set which status codes mean a failure. This is the one to get right.
5. Leave the thresholds at their defaults to start, then save.

Spraying is one password tried once against a hundred accounts from a hundred addresses. No lockout fires and no rate limit fires, which is exactly why it works.

There is no universal answer. A form that re-renders with "wrong password" answers 200 and answers 302 when it worked, so for that application 200 is the failure. An API answers 401.

Press Look at the log now, sign in wrongly once, and see exactly which code your application produced. Get it backwards and every successful login is reported as an attack, which is worse than no detection because people learn to ignore the alerts.

It reads the access log, so it sees the address, the path, the method and the status. It never sees a username and it never sees a password.

Seeing usernames would mean reading request bodies, which is where the passwords are, and a security feature that starts reading passwords has become the problem it was supposed to prevent.

All three spray rules have to hold at once, because any one alone is an ordinary Monday morning. A busy login page has plenty of failures. A large office has plenty of addresses. Everybody typing their password wrong once is exactly "few per address".

If you get false alarms, raise the minimum number of addresses first. That is the number that separates a spray from a bad morning.

The same test run over hours instead of minutes, because somebody who knows detectors use five minute windows simply waits six. It costs nothing to run both.

Login watch reports rather than blocks, because a false positive would lock out a whole office. Once you know the shape is real, add the addresses to an access list or tighten the rate limit on the login path.