Authentication Anomaly Analyzer Guide: Spot Suspicious Logins

Login logs are noisy by nature. Every successful sign-in, every mistyped password, and every forgotten-password attempt adds a line, and a busy system produces thousands of lines a day. Inside that noise, a few patterns matter far more than the rest: many failed attempts for one account in a short time, one account tried from many different addresses, and a sudden burst of failures across many accounts. Those patterns can indicate guessing attacks, credential stuffing, or a shared problem such as a broken sign-in page, and telling those apart starts with counting, not guessing.

The Authentication Anomaly Analyzer tool spots repeated failures and many-IP patterns in pasted login lines. You paste log lines, and it counts attempts, failures, and flagged users, highlighting the accounts and patterns that stand out. It analyzes text you paste; it does not connect to your authentication system, block any address, lock any account, or prove that an attack is happening. A flagged pattern is a reason to investigate, not a verdict, and the difference between an attack and a legitimate explanation, such as a user travelling, a shared office network, or a misconfigured device retrying a stale password, can only be settled with more evidence than a count alone provides.

The counting itself is straightforward, and that is its strength. For each user, count total attempts, count failures, and count distinct IP addresses. A failure rate is failures divided by total attempts, and a distinct-IP count shows how widely the attempts are spread. A user with 50 attempts, 48 failures, and 1 IP address looks different from a user with 50 attempts, 48 failures, and 40 IP addresses: the first suggests one source persistently guessing, while the second suggests a distributed attempt, or a legitimate user behind a network that changes addresses frequently. The same numbers, read with the IP count alongside, point at different investigations.

A worked example you can follow

Take a sample log for one user, ana, with 60 login lines in one hour: 8 successes and 52 failures, from 3 IP addresses. First, the failure rate: 52 divided by 60 equals about 0.867, or about 87 percent, since 52 times 100 divided by 60 equals about 86.7. That is a high failure rate, and it deserves attention. Next, the successes: 8 successes among 60 attempts means the account was eventually accessed, which raises the stakes, because a guessing attack that eventually succeeds is more serious than one that never does. The 3 IP addresses need checking: if all 3 belong to networks the user is known to use, the pattern may be a device retrying an old password, but if none are familiar, the successful logins need urgent review, including whether the password should be changed and sessions revoked.

Now take a sample for a second user, ben, with 40 lines: 40 failures, 0 successes, from 38 distinct IP addresses. The failure rate is 40 divided by 40, which equals 1, or 100 percent, and the distinct-IP count is 38 out of 40 attempts, which is nearly one new address per attempt. That combination, total failure plus wide distribution, is the classic shape of a distributed guessing attempt, and it points at a different response from ana's case: rate limiting, address blocking, and account protection, rather than a password conversation with the user. A third sample shows the benign end of the scale: a user with 12 lines, 2 failures, and 10 successes, from 1 IP address, giving a failure rate of 2 divided by 12, or about 17 percent. Two mistyped passwords followed by successful logins is ordinary human behaviour, and flagging it as an anomaly would be a false alarm. The lesson is to judge counts together, rate plus distribution plus outcome, never any one number alone.

When you paste logs for analysis, protect privacy and security in the process. Logs can contain usernames, addresses, and other identifying details, and pasted text should be handled accordingly: use samples that are necessary for the check, avoid pasting secrets or tokens that sometimes appear in log lines, and do not share the analyzed output more widely than the investigation needs. The analyzer's job is to surface patterns; your job is to handle the underlying data responsibly.

Common mistakes to avoid

The first mistake is treating a flag as proof of attack and blocking a legitimate user on a count alone; always corroborate with address familiarity, timing, and whether any attempt succeeded. The second mistake is the opposite, dismissing a high failure rate because the user has not complained; attackers do not complain, and a silent account compromise is discovered in logs, not in support tickets. The third mistake is analyzing a single hour in isolation, when a pattern spread over days, at a low daily rate, can be just as deliberate and harder to see. The fourth mistake is pasting logs that contain secrets or tokens into any tool without checking the lines first; redact credentials and tokens before pasting anything, every time.

The Word Counter tool confirms how many log lines you pasted, and the CSV to JSON Converter tool helps restructure tabular log exports for other tools. For background on protecting accounts, see HTTP Security Headers Guide.

Checking the result before you act on it

Before acting on an analyzer result, confirm the sample covers the right time window, confirm the counts by spot-checking a few lines by hand, check whether flagged addresses are known to the user, and check whether any flagged attempt succeeded. Only then choose a response proportionate to the evidence: a password reset and session review for a possibly compromised account, rate limiting or blocking for a distributed guessing pattern, and a fix to the sign-in flow when the pattern turns out to be a system fault. Counting well is what makes each of those responses defensible, because it replaces suspicion with numbers that can be shown, checked, and explained.