Reading Auth Failures and Designing Lockouts

Put a transfer server on the internet and within hours its log begins filling with failed logins. New administrators react in one of two wrong ways: panic — treating every failure as an attack in progress — or, a few weeks later, numbness, scrolling past everything including the entry that mattered. Both reactions come from the same gap: failed logins are not one thing. A typo, a scheduled job running on a stale password, a brute-force run, and a careful low-and-slow campaign all land in the same log, and they look completely different once you know the signatures.

Reading those signatures is the first half of this article. The second half is what you build with that knowledge: lockout and throttling rules that make password guessing uneconomical without handing attackers a way to shut off your own partners — because a badly designed lockout policy does exactly that, locking the victim account while the attacker shrugs and moves on.

This article — part of our Authentication on Transfer Endpoints series — gives you annotated log excerpts for each signature, starting numbers for thresholds, an alerting shortlist that fires on patterns instead of noise, and a runbook for the day a partner locks themselves out.

The Anatomy of a Failed Login Line

Every useful authentication log line answers five questions: when (timestamp), who was claimed (the account name presented), from where (source IP address), over what (protocol or interface — FTP, FTPS, SFTP, HTTPS, admin console), and what happened (success, or failure with a reason: bad password, unknown user, key rejected). Formats differ by server, but the fields are universal, and a server that omits one of them is blinding you. A Windows transfer server such as Sysax Multi Server records login attempts per account across all of its protocols in its activity log, which is exactly the raw material this article works with.

Single lines, though, tell you almost nothing — the signature lives in the pattern across lines: how many accounts, how many sources, what tempo, and whether a success ever appears. The excerpts below use a simplified neutral format so the patterns stand out; your server's log will differ cosmetically and match structurally. Getting logs collected, kept, and searchable in the first place is its own discipline, covered in our transfer logging and audit series.

The Four Signatures, Annotated

Signature 1: the human typo

The most common failure in any log, and the one your lockout policy must forgive gracefully:

Tue 09:12:31  AUTH FAIL  user=jmorris      ip=10.4.2.17      proto=SFTP   reason=bad password
Tue 09:12:44  AUTH FAIL  user=jmorris      ip=10.4.2.17      proto=SFTP   reason=bad password
Tue 09:13:02  AUTH OK    user=jmorris      ip=10.4.2.17      proto=SFTP

The tells: one known account, one familiar source address (here an internal one), two or three failures a few seconds apart — human-speed, not machine-speed — during working hours, ending in a success. Someone fat-fingered a password, swore quietly, and got it right on the third try. A variant ends not in success but in silence followed by a helpdesk ticket: that is a forgotten password, not an incident. Neither deserves a lockout, an alert, or a second of investigation.

Signature 2: the stale credential

The most common "attack" you will ever investigate is your own scheduler, or a partner's:

Tue 02:00:03  AUTH FAIL  user=acme-orders  ip=203.0.113.77   proto=SFTP   reason=bad password
Tue 02:15:03  AUTH FAIL  user=acme-orders  ip=203.0.113.77   proto=SFTP   reason=bad password
Tue 02:30:03  AUTH FAIL  user=acme-orders  ip=203.0.113.77   proto=SFTP   reason=bad password
Tue 02:45:03  AUTH FAIL  user=acme-orders  ip=203.0.113.77   proto=SFTP   reason=bad password
    ... identical, every 15 minutes, around the clock, for days ...

The tells: metronome regularity — the same second of every interval, because a scheduler is doing the retrying; one account, one source, and that source is the expected one for the account; no success, ever; and a start time that, if you check, coincides suspiciously with a credential rotation or a config change. No human fails a login at 2:00 a.m. and again at exactly 2:15:03. This is automation faithfully presenting a password that stopped being valid — usually because a rotation was completed on the server but never propagated to the job, the failure mode the overlap window in the partner credential lifecycle exists to prevent. It is noise to an attacker-hunter but urgent to the business: whatever that job was supposed to transfer is not moving.

Signature 3: brute force on one target

The classic attack signature — one source hammering one door:

Tue 03:41:07  AUTH FAIL  user=admin        ip=198.51.100.23  proto=FTP    reason=bad password
Tue 03:41:08  AUTH FAIL  user=admin        ip=198.51.100.23  proto=FTP    reason=bad password
Tue 03:41:09  AUTH FAIL  user=admin        ip=198.51.100.23  proto=FTP    reason=bad password
Tue 03:41:11  AUTH FAIL  user=root         ip=198.51.100.23  proto=FTP    reason=unknown user
Tue 03:41:12  AUTH FAIL  user=ftpuser      ip=198.51.100.23  proto=FTP    reason=unknown user
Tue 03:41:13  AUTH FAIL  user=test         ip=198.51.100.23  proto=FTP    reason=unknown user
    ... hundreds to thousands of attempts, machine-paced ...

The tells: machine tempo — multiple attempts per second, no human pause; a single unfamiliar source; and target accounts drawn from the universal guess list — admin, root, test, ftp, backup — many of which do not exist on your server, hence the unknown user reasons. This is opportunistic scanning that every internet-facing endpoint receives; the sender is running down a list of addresses, not studying you. It looks dramatic and is the easiest signature to defend against: per-source throttling shuts it down mechanically, and accounts with real names and real passwords are not meaningfully at risk from it. The full defense stack — including automatic source banning — is the subject of our brute force protection series.

Signature 4: the low-and-slow spray

The signature that per-account thresholds are structurally blind to:

Tue 04:02:19  AUTH FAIL  user=acme-orders  ip=192.0.2.140    proto=SFTP   reason=bad password
Tue 04:09:47  AUTH FAIL  user=payroll-push ip=192.0.2.140    proto=SFTP   reason=bad password
Tue 04:17:02  AUTH FAIL  user=jmorris      ip=192.0.2.140    proto=SFTP   reason=bad password
Tue 04:24:55  AUTH FAIL  user=bravo-inv    ip=192.0.2.140    proto=SFTP   reason=bad password
Tue 04:31:36  AUTH FAIL  user=dwhite       ip=192.0.2.140    proto=SFTP   reason=bad password
    ... one or two tries per account, many accounts, for hours ...

The tells: many valid account names — which means the attacker has learned your naming somehow, making this more targeted than signature 3 — but only one or two attempts against each, spaced out politely. This is password spraying: trying one likely password across many accounts, precisely tuned to stay under per-account lockout thresholds. Viewed account by account, each entry looks like a lone typo; viewed by source, one address has now failed against a dozen different accounts, which no legitimate anything ever does. That rotated perspective — counting failures per source and per time window, not just per account — is what catches it. A patient attacker spreads the same pattern across multiple source addresses and days, which is why the aggregate view ("distinct accounts failed against, per source, per day") belongs in your routine log review rather than only in real-time rules.

The Signatures at a Glance

Lockout Design: Stopping Attacks Without Punishing Partners

A lockout temporarily disables logins for an account after too many failures; throttling slows or blocks attempts from a source instead. They exist to break the economics of guessing — an attacker who gets five tries per hour instead of five per second needs centuries. But the naive version, "lock any account after a few failures until an admin unlocks it," creates two problems bigger than the one it solves.

First, a hard per-account lockout is a denial-of-service switch that anyone on the internet can flip. An attacker who knows or guesses your partner's account name — and account names are the guessable half of a credential — can deliberately fail a handful of logins against it and lock your partner out of their own flow. The account being attacked is the victim; permanent-until-admin lockout punishes the victim while costing the attacker nothing. Second, the stale-credential signature above walks straight into per-account lockouts: a partner whose job retries a dead password every fifteen minutes locks the account before anyone has read the log, converting a config error into an outage.

Design around both problems with three principles:

• Count per source first. The offending unit in signatures 3 and 4 is the source address, not the account. Throttle and ban misbehaving sources — the automated, fail2ban-style version of this is covered in brute force protection — and most internet noise disappears without any account ever locking.
• Make per-account lockouts soft. Generous threshold, automatic expiry after minutes, never permanent, and always paired with a notification so a lockout is a signal someone sees rather than a silent outage. Progressive delay — each failure adding seconds before the next attempt is accepted — achieves the same economics with no lockout state to manage at all.
• Change the math for known-source accounts. A partner or service account restricted to its known source addresses can only accumulate failures from those addresses — the internet cannot touch it, so the lockout question barely arises. Allowlisting is the quiet prerequisite that makes gentle lockout policies safe.

Starting Numbers

Every environment tunes differently, but tuning needs a starting point. These defaults are deliberately conservative in both directions — hard on sources, forgiving on accounts — and safe to adopt as written, then adjust against a month of your own log data:

LOCKOUT AND THROTTLING STANDARD - STARTING VALUES

Per SOURCE (primary control):
  10 failures within 5 minutes  -> block source for 30 minutes
  3 blocks in 24 hours          -> block source for 24 hours
  Applies to all protocols; admin interface counts double.

Per ACCOUNT (safety net, soft):
  10 failures within 15 minutes -> lock account 15 minutes,
                                   auto-unlock, notify admins
  Never permanent. Manual-unlock-only is reserved for
  confirmed-incident response, not for policy.

Admin console:
  5 failures within 15 minutes  -> lock 30 minutes + alert.
  Console reachable from admin networks only (which makes
  this rule almost never fire -- that is the point).

Partner and service accounts:
  Source-allowlisted where possible. Lockout of one of these
  accounts pages the on-call and triggers the partner-lockout
  runbook -- it is a business outage, not just a security event.

Review: compare thresholds to actual log data twice a year.
Document every change and the incident or data that drove it.

Two notes on using these numbers. A lockout threshold is not a password-strength substitute — the policy in password policy for transfer accounts is what makes even unlimited guessing hopeless; throttling just takes away the attempt volume too. And thresholds only protect interfaces they are enabled on: check that FTP, FTPS, SFTP, HTTPS, and the admin console are all covered, because attackers will find the one interface you forgot.

Alerting on the Right Patterns

Raw failure counts make terrible alerts — signature 3 alone would page you nightly with events that need no human. Alert on patterns that are both rare and meaningful:

• Success after a failure streak. The fire-alarm line from the note above: an account succeeds after ten or more recent failures. Rare, cheap to detect, and exactly what a successful guess looks like.
• A service or partner account from a new source. These accounts log in from the same addresses for years; a first-ever source is either an undocumented change or a stolen credential in use. Both deserve a human within minutes.
• Any lockout of a partner or service account. Whatever the cause — stale credential, attack, or typo by an admin doing maintenance — files have stopped moving, and someone should know before the business does.
• Spray shape. One source failing against five or more distinct accounts in an hour. This is signature 4's fingerprint, invisible to per-account rules by design.
• Admin console failures — all of them. If the console is properly restricted to admin networks, every failure there is either an admin's typo or a serious problem. Low volume, high signal.

Everything else — the nightly guess-list noise, the banned sources, the typos — belongs in a weekly review summary, not a page. Alert fatigue is how real alerts die: every alert that a human ignores trains the humans to ignore alerts. Getting these patterns out of raw logs and into fired notifications is the pipeline work covered in transfer logging and audit.

The Partner Lockout Runbook

Eventually a partner account locks or a partner calls about failed logins, and the response should be a procedure, not improvisation:

1. Read the signature before touching anything. Pull the account's recent failures and classify: familiar source at metronome tempo is a stale credential; unfamiliar sources mean the account is under attack and the lockout is doing its job.
2. Contact the partner out of band — the named contact from your inventory, by phone or a known-good address. Never treat an inbound "please unlock us and remind me of the password" email as authentication; unlock requests are a social-engineering classic.
3. Stale credential: the partner updates their job with the current credential (or you re-run the rotation properly, with the overlap window from the partner credential lifecycle). The lock expires on its own; the fix is on their side.
4. Attack signature: leave the lock, tighten the account's source allowlist if it has none, and treat the credential as suspect — which may mean the emergency revocation drill rather than an unlock.
5. Record it. Date, signature, cause, fix, and anything that slowed you down — three entries of this log will tell you more about your thresholds than any vendor guidance.

The Short Version, and Where to Go Next

Failed logins are a language: typos are human-paced and end in success; stale credentials fail on a metronome from expected sources; brute force arrives machine-fast from strangers against guess-list names; sprays touch many valid accounts gently from one place. Read by source and pattern, not line by line. Then design enforcement to match: hard on sources, soft and self-expiring on accounts, allowlists on the accounts that matter, and alerts reserved for the patterns that are rare and real — above all, the success that follows a streak of failures.

From here: the partner credential lifecycle prevents the stale-credential signature at its source and covers the revocation drill this runbook borrows; service account hygiene sets up the per-job accounts and known sources that make these signatures readable at all; and the brute force protection series builds the automated banning layer that handles signatures 3 and 4 while you sleep.

Frequently Asked Questions