SDS Login Guard

SDS Login Guard protects WordPress password authentication against repeated failed login attempts using source-level, username/email-level, and known-account throttling. It is not a WAF, malware scanner, or DDoS service.

No. SDS Login Guard is completely standalone. This is important because one of the reasons we built it was to protect sites that intentionally leave the normal WordPress login location accessible.

When too many failed login attempts occur within the configured failure-counting window, SDS Login Guard temporarily rate-limits further login attempts from the affected source, username/email combination, or known WordPress account.

The cooldown is temporary, not a permanent account lockout. The login screen tells the user approximately how long they need to wait before trying again, but it does not reveal the number of failed attempts, the configured threshold, or whether the submitted username or email address belongs to a real account.

Login attempts made during an active cooldown are rejected without increasing the failure count or extending the cooldown. This prevents an attacker from repeatedly submitting requests to keep a legitimate user locked out indefinitely.

After the cooldown expires, another login attempt is allowed. If that attempt fails while the earlier failures are still within the active failure-counting window, a longer cooldown may begin. Cooldowns progressively increase up to the configured maximum. If the failure-counting window expires first, the escalation resets.

Entering the correct password during an active cooldown does not bypass the protection; the user must wait until the applicable cooldown expires. After the cooldown ends, a successful login clears the applicable targeted throttling state.

SDS Login Guard does not create a site-wide login lockout. Source-level cooldowns apply independently to individual client sources, so abusive activity from one source does not prevent unrelated visitors from logging in.

The login is still temporarily rejected until the cooldown period expires. The correct password does not bypass or extend the cooldown; once it expires, the user can try again.

No. They are rejected without increasing the failure count or extending the cooldown. This is an excellent FAQ because the reason is important: it prevents attackers from weaponizing Login Guard to create an indefinite lockout.

SDS Login Guard uses a failure-counting window and a cooldown timer for different purposes.

The cooldown determines how long additional login attempts are temporarily blocked. The failure-counting window determines how long recent failed attempts remain relevant for deciding whether the next cooldown should be longer.

For example, if repeated failures trigger a 1-minute cooldown, that cooldown may end while the earlier failures are still inside the active failure-counting window. The user is then allowed to try logging in again. If that new attempt also fails, SDS Login Guard can start a longer cooldown because the previous failures are still considered part of the same recent pattern of failed authentication.

This progressive behavior makes repeated password guessing increasingly expensive without creating a permanent lockout. Login attempts made while a cooldown is already active do not increase the failure count or extend the cooldown.

If the failure-counting window expires before another failed attempt occurs, the earlier failure history no longer contributes to escalation and the progressive cooldown sequence resets.

No. For a real WordPress account, known username and email aliases share account-level protection. Switching aliases does not increase the number of password guesses.

No. Invalid usernames, invalid email addresses, and incorrect passwords receive the same neutral credential error, and valid/invalid submitted usernames or email addresses receive equivalent identifier-level throttling behavior.

No. Protection is tied to the client source and authentication target rather than creating a global account lockout that an attacker could deliberately trigger against another user.

No. SDS Login Guard is designed to avoid creating a site-wide login lockout.

When a source generates too many failed login attempts, the cooldown applies to that source rather than to every visitor. During a coordinated attack, multiple attacking sources may each be rate-limited independently, while other visitors can continue logging in normally.

A source-level cooldown also affects login attempts only; it does not block visitors from viewing the website.

People sharing the same public internet connection may appear to the site as the same source and can therefore share a source-level cooldown. However, an attacker cannot trigger a single Login Guard cooldown that disables login access for the entire website.

SDS Login Guard uses several layers of protection because different types of failed login activity can indicate different kinds of attacks.

Username/email-level protection watches repeated failed login attempts using the same submitted username or email address from the same source. This protection applies whether the username or email address belongs to a real WordPress account or not. Treating valid and invalid login names the same way helps prevent attackers from learning which usernames or email addresses are registered on the site.

Known-account protection applies when WordPress can identify that the submitted username or email address belongs to a real user account. The username and email address for that account share the same account-level protection. This prevents someone from gaining extra password guesses simply by switching between a user's known username and email address.

Source-level protection watches the overall number of failed login attempts coming from the same client source, even when many different usernames or email addresses are being tried. This helps protect against password spraying, account enumeration, and similar attacks where someone repeatedly changes the login name in an attempt to avoid account-specific limits.

These protections work together. A single failed login may contribute to more than one protection layer, depending on the circumstances. If any applicable protection enters a cooldown, SDS Login Guard temporarily rejects further affected login attempts.

The protections are intentionally scoped so they do not create a site-wide login lockout. A source-level cooldown affects that particular client source, while username/email-level and known-account cooldowns apply only to the relevant source and login target. Unrelated visitors can continue logging in normally.

Yes. SDS Login Guard allows administrators to adjust the main failed-login thresholds and initial cooldown periods to suit the needs of their site.

The default settings are intentionally conservative and provide a balance between protecting against repeated password guessing and avoiding unnecessary inconvenience for legitimate users who mistype their login information.

SDS Login Guard also enforces safe limits on configurable values. This prevents the protection from being weakened through settings that are too permissive or made unnecessarily aggressive through settings that could create excessive lockouts.

The failure-counting window remains part of the protection model even after a cooldown ends. If another failed login occurs while earlier failures are still within that window, a progressively longer cooldown may begin. If the failure-counting window expires first, the escalation resets.

If the failure-counting window expires before another failed attempt occurs, the earlier failure history no longer contributes to escalation and the progressive cooldown sequence resets.

No. SDS Login Guard performs its login protection locally on your WordPress site.

The plugin does not require an SDS cloud service, remote reputation database, or external authentication service to determine whether a login attempt should be rate-limited.

SDS Login Guard does not send submitted usernames, email addresses, passwords, IP addresses, or authentication activity to SDS for its normal protection functions.

This also means that Login Guard continues to protect the site if an external SDS service is unavailable because its core protection does not depend on one.

SDS Login Guard never stores submitted passwords.

It also avoids storing raw submitted usernames, email addresses, and client IP addresses in its throttling records. Instead, the plugin uses site-specific cryptographic fingerprints where it needs to recognize the same source or submitted login information again.

When a submitted username or email address belongs to a real WordPress user, Login Guard may associate the protection state with that user's existing WordPress user ID. This allows username and email aliases belonging to the same account to share account-level protection without storing the submitted login information as part of the throttle record.

Throttle records are temporary. A record may remain after a cooldown ends if recent failed attempts are still within the active failure-counting window and are needed to determine whether another failure should trigger a longer cooldown. Once the record is no longer needed for failure counting or an active cooldown, it becomes eligible for scheduled cleanup.

A successful login clears the applicable targeted throttling data immediately.

No. SDS Login Guard is not designed as a full login-history or visitor-analytics system.

The plugin retains the temporary information needed to count failed authentication attempts, enforce cooldowns, and show administrators the current operational state of the protection.

Successful and failed authentication activity can also generate privacy-conscious security events that other compatible SDS security tools may use, but Login Guard itself does not maintain an indefinite historical log containing every login attempt.

This keeps the plugin focused on login protection and avoids creating a large, continuously growing authentication database.

SDS Login Guard is designed to keep its database usage bounded and temporary.

Throttle records are stored in a dedicated plugin table rather than being mixed into general WordPress options or user metadata. Records that are no longer needed for active failure counting or cooldown enforcement are removed through scheduled cleanup.

The plugin also limits how many individual username/email throttle records one source can create. If a source attempts large numbers of different login names, SDS Login Guard uses bounded shared protection rather than allowing unlimited database-row creation.

Under an unusually large distributed attack, the plugin may temporarily retain additional active security state rather than discard protection that is still needed. Large-scale network attacks are still best filtered upstream by a hosting provider, reverse proxy, CDN, or firewall.

SDS Login Guard is designed to add very little overhead to ordinary WordPress traffic.

Its protection is focused on authentication rather than acting as a general-purpose PHP firewall or traffic-analysis system on every page request. Components needed for authentication protection are loaded only when required, and repeated security-state lookups within the same authentication request are minimized.

Administrative live-status updates are also deliberately lightweight. They run only while the Status section is expanded and the browser tab is visible.

As with any security control, failed authentication attempts require some processing, but Login Guard is specifically designed to keep that work bounded and efficient.

Yes. SDS Login Guard includes support for identifying the real visitor source when a WordPress site is behind Cloudflare.

For security, the plugin does not blindly trust a visitor-IP header simply because one is present. Cloudflare-specific client-address information is trusted only when the immediate connection to the server can be verified as coming from Cloudflare infrastructure.

This helps prevent a direct visitor from forging a Cloudflare header in an attempt to manipulate Login Guard's source-level protection.

Sites whose server or hosting configuration already restores the original visitor IP address can instead use the normal server-provided client address.

That is fully supported.

If your hosting stack, reverse proxy, or web server is already configured so that WordPress receives the real visitor address through the normal server connection information, SDS Login Guard can use that address directly.

The Login Guard Status screen reports how client identification is currently being handled, allowing administrators to confirm that the plugin has a usable source address for rate limiting.

Correct client identification is important because source-level protection should apply to the actual visitor rather than unintentionally grouping unrelated visitors behind a proxy address.

No. If your site does not need XML-RPC, disabling it at the server, hosting, or reverse-proxy level is generally preferable.

Blocking an unnecessary endpoint before the request reaches WordPress reduces both attack surface and server resource usage.

If XML-RPC is intentionally enabled, standard WordPress password authentication performed through it can still benefit from SDS Login Guard's authentication protection. However, Login Guard should not be considered a reason to enable XML-RPC on a site that otherwise has no use for it.

No. WordPress Application Passwords use a separate authentication mechanism from the normal username/email and password login process protected by SDS Login Guard.

Application Passwords are primarily intended for programmatic access such as APIs and integrations rather than interactive WordPress logins.

If your site does not require Application Passwords, access to that feature can be restricted separately as part of a broader WordPress security-hardening policy.

SDS Login Guard is designed to protect authentication that continues to use WordPress's normal authentication system.

Changing or hiding the URL of the WordPress login page does not by itself prevent Login Guard from working. For example, a login-path plugin that changes how users reach the normal WordPress authentication process can still benefit from Login Guard protection.

A completely custom login system may behave differently if it bypasses WordPress's standard authentication hooks or implements its own credential-validation process. Compatibility with such systems should therefore be verified before relying on Login Guard to protect them.

SDS Login Guard does not require SDS Hide Login Path and can be used with the standard WordPress login location.

Yes.

SDS Login Guard includes a master protection control in its administration screen. This allows an administrator to temporarily disable login protection while leaving the WordPress plugin itself active.

While protection is disabled, the Login Guard administration page, settings, Status information, and maintenance controls remain available.

This is useful for troubleshooting or configuration work because the administrator does not need to deactivate the entire plugin simply to suspend its authentication protection temporarily.

Disabling protection stops SDS Login Guard from affecting WordPress authentication while leaving the plugin itself active.

While protection is disabled:

• failed logins are not counted by Login Guard;
• cooldowns are not enforced;
• neutral credential-error handling is disabled;
• the public brute-force-protection notice is not displayed;
• Login Guard does not apply its normal authentication protection.

Current throttling data is cleared when the protection state changes so an old cooldown cannot unexpectedly reappear when protection is later enabled again.

Your configured plugin settings are preserved.

Deactivating SDS Login Guard through the WordPress Plugins screen stops the plugin from running entirely.

WordPress then returns to its normal authentication behavior. This includes WordPress's default login error handling, which may distinguish between an unknown username or email address and an incorrect password. This might also reveal to the source the existence of specific credentials, such as a username or email address, if they match a valid user account.

Deactivation does not silently leave behind authentication hooks or other active protection outside the plugin.

Plugin configuration and stored data are preserved on deactivation so the plugin can be reactivated without being configured again. Permanently deleting/uninstalling the plugin performs the plugin's normal data-cleanup process.

Clear All Throttling Data removes the temporary failure-counting and cooldown information currently retained by SDS Login Guard.

This immediately removes active Login Guard cooldowns and recent failure history used for progressive rate limiting.

It does not delete:

• Login Guard settings;
• WordPress users;
• passwords;
• other WordPress content or configuration.

This control can be useful during troubleshooting or testing, but clearing throttling data also means that currently rate-limited sources can immediately begin attempting authentication again.

A retained throttle record does not necessarily mean that someone is currently blocked.

SDS Login Guard uses temporary records both for active cooldowns and for recent failed-login history. A cooldown may have ended while the failures that caused it are still within the active failure-counting window.

Keeping that recent history allows Login Guard to recognize continued failed authentication and, when appropriate, start a progressively longer cooldown.

Once the retained information is no longer needed for either failure counting or active protection, scheduled cleanup removes it.

For this reason, the number of Retained throttle records can be greater than the number of currently active cooldowns.