Aegisify company logo
Aegisify WAF Authentication Defense2026-08-12T03:08:15+00:00
Aegisify WAF — Authentication Defense

Stop Repeated Login Abuse Without Turning the Targeted Account Into the Denial-of-Service Victim

Aegisify WAF 1.20.13 correlates failed WordPress authentication by source and by a keyed account fingerprint, detects high failure volume, one-source/many-username spraying, and distributed many-source targeting, then temporarily blocks the attacking source instead of globally locking the targeted user.

Protect the login path without storing the credential.Aegisify does not need the password for correlation, and it avoids storing the raw username in its authentication-defense state by using an HMAC-based account fingerprint.
1Correlatefailures + identities
2Detectspray + stuffing
3Containsource ban
Authentication Signals

Three Ways Repeated Login Failure Becomes Actionable

The current engine tracks both activity from an individual source and activity against a fingerprinted account inside a bounded correlation window.

Click a signal to expand

01Failure Volumeone source
A source that reaches the configured total-failure threshold inside the correlation window is temporarily blocked even if it repeatedly targets one account.
02User Spraymany usernames
A source that fails against enough distinct account fingerprints is treated as a username/password spraying pattern and can be contained before raw failure volume becomes extreme.
03Distributed Targetmany sources
Aegisify also tracks distinct source fingerprints associated with the same account fingerprint, allowing it to surface distributed credential-stuffing pressure across multiple IP addresses.
04Temporary Blocksource only
When a threshold is reached, the source IP receives a temporary authentication block and is registered with the shared blocklist. The targeted account is not globally locked.
05Successreduce typo pressure
A successful login reduces the source’s accumulated failure count and clears its distinct-username set, helping ordinary typing mistakes decay without erasing the broader attack evidence already logged.
06Evidenceprivacy-aware
Logs can include counts, reason, block duration, a shortened account fingerprint and authentication error code. Passwords are not stored by this correlation engine.
Default 1.20.13 Thresholds

A Ten-Minute Window With Multiple Correlation Triggers

Defaults are conservative starting values that should be tuned against the site’s real authentication traffic and network topology.

01 — Window

600 Seconds

The default correlation window is 10 minutes. Runtime validation constrains the setting between 60 and 3,600 seconds so failure state cannot become an unbounded historical reputation database.

02 — Volume

12 Failed Attempts

A source reaching 12 failures inside the default window can trigger containment. The configurable implementation permits bounded adjustment for sites with different login patterns.

03 — Username Spread

6 Distinct Account Fingerprints

Six different targeted usernames from one source is the default spray threshold. This catches breadth-based probing that may stay below a simple per-account failure limit.

04 — Distributed Pressure

8 Distinct Source IPs + Minimum Local Activity

The default distributed-account signal uses eight distinct source fingerprints against the same account fingerprint, with a minimum local-source failure count of three before the current source is blocked for that condition.

Default containment: a qualifying source receives a 900-second temporary block. The configurable block duration is bounded from 60 seconds through one day.
Privacy-Aware Correlation

Use a Keyed Account Fingerprint Instead of Keeping the Raw Username in State

Authentication defense needs to know whether attempts target the same account; it does not need to preserve the account name in its correlation record.

Account Identity

HMAC-SHA256 Fingerprint

The submitted username is normalized to lowercase and keyed with WordPress authentication salt to create an HMAC-SHA256 fingerprint. Runtime state stores that fingerprint rather than the raw username.

Source Identity

IP Correlation

Source-level state tracks total failures and distinct account fingerprints. Account-level state tracks hashed source IPs so Aegisify can count how many different network sources are targeting the same account.

Credential Boundary

No Password Storage

The pre-authentication hook receives WordPress authentication input as part of the normal login flow, but the defense logic does not store or log the submitted password. Correlation is based on failure events, source and account fingerprint.

Containment Model

Block the Attacking Source, Not the Account Being Attacked

Account lockouts can be weaponized against a known administrator username. Aegisify’s authentication-defense block is source-oriented.

Before WordPress authenticates a request, Aegisify checks whether the current source is under an active temporary authentication ban or a global block. An active temporary ban returns a 429 response with a retry-after value. Administrator-created or permanent global blocks remain authoritative.

When a new threshold is reached, Aegisify stores the source’s temporary expiration and registers the block with the shared blocklist, including the reason and bounded evidence. That makes the active containment visible to the broader WAF block-management workflow instead of hiding it in an isolated transient.

If Adaptive Defense is available, a credential-stuffing block also records an offense signal for that source. This can contribute to broader source-level context without changing the core rule that the targeted WordPress account itself is not globally locked by Authentication Defense.

Network caution: many legitimate users can share one public IP through offices, mobile carriers, VPNs, universities, or proxies. Tune thresholds carefully and validate trusted-proxy client-IP detection before aggressive source blocking.
Allow and Recovery Boundaries

Keep Known Traffic From Becoming False Authentication Pressure

Source decisions are only as accurate as the IP and trust configuration around them.

01

Validate the Real Client IP

Behind a CDN, proxy or load balancer, confirm that Aegisify receives the correct trusted client address. Incorrect forwarding trust can collapse many users onto one apparent source.

02

Use Narrow Overrides and Whitelists

The authentication-defense path can bypass trusted overrides and configured IP/CIDR allow entries. Keep exceptions specific and documented rather than turning off login protection for convenience.

03

Review Evidence Before Raising Sensitivity

Use Logs, Overview, active block management and Attack Story context to determine whether failures represent one attacker, distributed automation, a broken application client, or legitimate users making mistakes.

Why Multiple Triggers Matter

Volume Alone Misses Low-and-Slow Credential Abuse

A fixed failed-login counter sees repetition, but it does not explain whether an attacker is concentrating on one account or spraying many accounts.

Aegisify combines total failures, distinct account fingerprints from one source, and distinct source fingerprints against one account. That gives defenders three different views of authentication pressure while keeping the final containment source-oriented. The result is more useful than simply lowering a login-attempt threshold until legitimate users begin locking themselves out.

Protect WordPress Authentication

Correlate the Pattern Instead of Punishing the Target Account

Aegisify WAF adds source-oriented credential-stuffing and spray containment to the WordPress login flow while keeping password data out of the correlation record.

Authentication Defense FAQ

Common Questions

Does Aegisify lock the targeted WordPress account?

No. The current defense is explicitly source-oriented. It temporarily blocks the attacking source so an attacker cannot intentionally lock a victim account for everyone.

Does the feature store raw usernames or passwords?

The correlation state uses a keyed account fingerprint rather than the raw username, and the defense does not store or log submitted passwords.

What happens after a successful login?

The source’s accumulated failure count is reduced and its distinct-username set is cleared, helping ordinary user mistakes decay without erasing already-recorded event evidence.

Defend the Login Boundary

Detect Credential Pressure From Both Directions.

Aegisify WAF correlates many failures from one source and distributed failures against one account fingerprint, then contains the source without turning the user account into the lockout target.