Login Security

🔐 Login Configuration

The Login tab lets you enable or disable the entire access security system and configure the core brute-force protection parameters: failed attempt limit, temporary block duration, conditions for permanent blocks, plus email notifications.

Configuration Parameters

Protection Flow

Detailed Behavior

• Temporary Block: Applied after exceeding the failed attempt limit. The IP is blocked for the configured time (default 15 min). When it expires, the IP regains access automatically.

• Permanent Block: Activated when an IP accumulates multiple temporary blocks (default 3). Requires manual administrator intervention to unblock.

⏱️ Logout Due to Inactivity (PRO)

Logs out users with the roles you choose after the set time without using their session. It prevents a dashboard left open on someone else's computer (office, hotel, internet café) from being available to anyone.

• Minutes without activity: between 5 and 1440 (24 hours). Default: 30.
• Roles: Administrator and Editor by default.
• What counts as activity: real use (mouse, keyboard, scrolling, taps) in any tab of the site. The periodic WordPress background check (heartbeat) does not count.
• Prior warning: one minute before, a notice with a "Stay logged in" button appears. When the session closes, the user returns to the login screen with the message "Your session was closed due to inactivity".

Each device counts separately: being active on your phone does not keep open a session forgotten on another computer. Configure it in Login Security → Login.

📬 New Login Alert (PRO)

When someone logs into an account from a browser or device never used before, or from a new country, SeenSecure emails the user the details of the login (date, device, IP and country).

• "It was me": the device becomes trusted and no further alerts are sent about it. It only works when the link is opened in the same browser and device used to sign in: someone reading the email elsewhere cannot mark their own device as trusted.
• "It wasn't me": all sessions of the account are closed, on every device, and the current password stops working (the attacker knows it). The owner receives the standard WordPress email to choose a new one: the alert link never opens the password change directly.
• Suspicious IP block: when “It wasn't me” is confirmed, the IP used to sign in goes to IP Management → Blocked for 30 minutes (configurable in the card; 0 = do not block), with its reason in the history, and is unblocked automatically. This way the attacker cannot try again while the owner changes the password. It is not blocked if it is the same IP the button is pressed from (the owner would be locked out) or if it is whitelisted.
• Administrators and Editors: the site administrator also receives a copy with the same buttons (optional, with its own email).
• Safe against email scanners: the buttons open a confirmation page; the action only runs when you click on it. Each link works once and expires after 7 days.
• No alerts when you enable it: the first time each user logs in after enabling it, their device and country are registered without an alert.

The device is recognised by its own browser cookie; the country, with the same geolocation as the rest of the firewall. Configure it in Login Security → Login.

🖥️ Concurrent Session Limit (PRO)

Limits how many sessions the same user of the roles you choose can have open at the same time (from 1 to 10). If they log in on a new device when the limit is already reached, before they can use the site they see a screen with their other sessions (browser, IP and login time) and choose:

• «Close that session and continue here»: the oldest session is closed and they log in on this device. With a limit of 1 the other one is closed; with 2, the first of the two; and so on.
• «Cancel and do not log in»: they do not log in and their other sessions stay open.
• The other device is told: back on the login screen it sees that its session was closed because someone logged into the account from another device, with the advice to change the password if it was not them.
• Until they choose, nothing works: the new session cannot browse or use AJAX or the REST API until it answers.
• Nobody gets locked out: another session can always be closed to log in. Sessions already open when it is enabled are kept.

Why limit sessions?

Every open session is a door into the account. Without a limit, a stolen password or a copied session cookie can be used alongside the owner without anyone noticing, and sessions forgotten on other computers stay open for days.

Attacks it prevents or exposes

• Stolen password used in parallel (phishing, leaks, reuse): with a limit of 1 the attacker cannot be in at the same time as the owner without kicking them out, and the owner sees the warning. When the owner logs back in, it is the attacker who gets kicked out.
• Session hijacking with a stolen cookie (browser malware, public Wi-Fi): the cookie stops working as soon as that session is closed.
• Shared accounts among several people, for example a paid subscription or course used by several people at once.

What it does not do: it does not stop someone who already knows the password from logging in; it makes it visible and forces them to kick the owner out. Combine it with two-step verification and the new login alert.

Recommended: 1 for Administrators; 2 or 3 if the same person uses a computer and a phone. Configured in Login Security → Login.

🛡️ CAPTCHA

The CAPTCHA system protects your forms against bots and automated attacks. It offers 7 different verification modes to adapt to each site's needs.

Available CAPTCHA Modes

Forms to Protect

You can select which forms have CAPTCHA applied:

• Login: Protects the login form against brute force.

• Register: Prevents mass creation of fake accounts.

• Comments: Prevents automated spam in comments.

• Password Reset: Blocks password reset attacks.

Google reCAPTCHA Configuration

For modes using Google reCAPTCHA (v2, v3, Hybrid), you need to register your site at Google reCAPTCHA Admin and obtain the following keys:

Anti-Abuse Protection

🔑 Two-Factor Authentication (2FA)

Two-factor authentication adds an extra layer of security by requiring a second verification factor in addition to the password. The system supports TOTP (Time-based One-Time Password) via authenticator apps and email codes as an alternative.

Initial Activation by Admin

Before configuring global 2FA policies, the admin must activate 2FA on their own account. The system generates a QR code with the TOTP secret that must be scanned with an authenticator app (Google Authenticator, Authy, Microsoft Authenticator, etc.).

Global 2FA Policy

User Management

The admin panel allows searching users, resetting or disabling 2FA for specific accounts, and resending recovery codes. Includes statistics cards: Users with 2FA, Without 2FA, Policy status, Total users, and Email code status.

🚫 Anti Session Hijacking

Detects when a logged-in user suddenly switches country mid-session — the typical sign that someone has stolen their credentials or session cookie, for example after intercepting it on public or shared wifi. The system stores the country each user logs in from and compares it on every subsequent request.

Configuration Parameters

Action Modes

What are country ISO codes?

They are the standard 2-letter codes (ISO 3166-1 alpha-2) that identify each country online — the same ones used in country domains (.es, .fr...) and address forms. Write them in uppercase, separated by commas if you add more than one. No need to memorize them: just the country you or your team usually connect from.

Your country not in the table? Search "ISO 3166-1 alpha-2 code" followed by your country's name, or check the full official list at iso.org.

Email Notification

Enabling the "Email the administrator" checkbox means you'll receive an email at your WordPress contact address (Settings → General) every time a suspicious country change is detected on an active session. The email includes the affected user, the original country, the country the change was detected from, and whether the session was closed or only logged, so you can act if you consider it necessary even in Monitor mode.

Available on the PRO plan. Configurable from Login & 2FA → Anti-Hijack in the SeenSecure panel.

👤 Restricted Accounts

The restricted accounts system blocks common or dangerous usernames that attackers often use. When an IP attempts to access with multiple restricted names, it is automatically blocked and added to the permanent blacklist.

Blocked Usernames by Default

You can add or remove names from the list. Changes apply immediately.

IP Block Threshold

Configure how many attempts with restricted names from the same IP trigger a permanent blacklist block with reason login_blackname.

Recent Attempts Summary

The panel shows a summary table with the latest access attempts using restricted usernames, including the IP, attempted name, date/time, and whether it resulted in a block.

IPs Blacklisted via login_blackname

List of IP addresses that have been permanently blocked for exceeding the restricted name attempt threshold. You can unblock them manually from the Active Blocks section.

🏢 Automatic ASN Block (distributed attacks) (PRO)

A distributed brute-force attack does not come from a single IP: the attacker rents dozens of IPs from the same server or proxy provider (the same ASN) and tries usernames and passwords switching IP on every attempt. Since each IP only tries once or twice, none reaches the per-IP block limit.

This protection counts the different IPs from each provider that fail to log in within a time window. When they reach the minimum, it blocks the whole provider for the configured time.

• Different IPs to block: 5 by default (2 to 50).
• Window: 10 minutes by default (1 to 120).
• Block duration: 60 minutes by default (5 minutes to 7 days). It is lifted automatically.
• What is blocked: by default only the login, XML-RPC and the custom login URL. Optionally, the whole site.
• Every failure counts: wrong password, CAPTCHA, browser fingerprint, restricted username and XML-RPC.

Earlier step: invisible JS challenge

Before blocking, SeenSecure tries something softer. With just a few IPs failing (2 by default), the provider is put under watch: for 60 minutes, all its IPs get an invisible browser check when opening the login, wp-admin or the custom login URL.

• A real browser solves it on its own in milliseconds (a small proof of work using the browser’s cryptography) and the person sees the login as usual.
• A script bot (curl, Python…) does not run JavaScript and stays at the check: it never even submits the form.
• If IPs that already passed the challenge fail to log in (bots with an automated browser such as Puppeteer or Playwright), the provider is blocked sooner, without waiting for 5 IPs.
• Providers with recent legitimate users are never blocked: they are only watched.
• It does not apply to XML-RPC (used by apps, which cannot solve it) or to anyone already logged in to the dashboard. In firewall Monitor mode it is only logged.

It is shown in IP Management → ASN (“ASNs under watch” table, with a “Remove watch” button) and in the Traffic Log as asn_challenge. Configure it in the same card (IPs for watch and duration).

Safeguards

• It never blocks the provider of users who logged in successfully in the last 30 days (including yours).
• Allowlisted IPs are never blocked.
• Why only the login by default: an ASN can be an entire carrier; blocking only the login keeps the site visible to everyone.
• With the firewall in Monitor mode, it is logged but not blocked.

Where to see it and how to unblock

IP Management → Blocked ASNs lists each blocked provider with the reason, how many IPs attacked, the scope and how long it lasts, with an Unblock button. Blocks and unblocks are recorded in the IP Management history and, if enabled, you get an email with the ASN, the provider and the attack IPs.

Real example

In October 2026 a site protected by SeenSecure received, within minutes, login attempts from more than 45 different IPs, all from the same proxy provider. Each IP tried a dictionary username (admin, wpadmin, root…) only once. CAPTCHA and the browser fingerprint stopped them one by one; with this protection, at the fifth different attacker the whole provider is blocked and the rest of the attack never even reaches the form.

Configure it in Login & 2FA → Restricted accounts.

🛡️ Active Blocks

The Active Blocks section shows all currently active temporary and permanent blocks. It allows managing users and IPs that have been blocked for suspicious activity, offering options to manually unblock.

Blocks Table

The table includes the following columns:

• User/IP: Blocked username or IP address.

• Type: Permanent or Temporary, indicated with a color badge.

• Reason: Reason for the block (failed login, login_blackname, etc.).

• Attempts: Number of failed attempts recorded before the block.

• Blocked Since: Block start date and time.

• Expires: Expiration date (for temporary blocks).

Unblock

Each table row includes an "Unblock" button with confirmation. When clicked, it asks for confirmation before removing the block. This prevents accidental unblocks.

📊 Event History

The Event History logs all login security-related activities: successful and failed logins, temporary and permanent blocks, manual unblocks, and password changes. Provides filters and pagination for easy navigation.

Event Types

Available Filters

• Event Type: Dropdown to select a single event type (or "All").

• Username: Text field to filter by specific user.

• IP Address: Text field to search events from a specific IP.

Pagination & Display

• Rows per page: Selector with options 10, 20, 50, 100, 200.

• Client-side pagination: Page navigation is handled in the browser without reloading.

• Country flags: Flags are displayed from ISO country codes to identify the origin of events.

🔑 Password Policy

Requires a minimally strong password when creating or changing it, both on the password reset screen and on the WordPress user profile. The user sees in real time, as they type, which requirements are missing — without WordPress's original form being touched.

Configurable requirements

Each requirement is independent: only the ones you enable are required.

Where it applies

It's checked on the two native WordPress screens where a password is set: the password reset screen (after requesting "Lost your password?") and the password change on the user profile in the WordPress dashboard. If the password doesn't meet the enabled requirements, WordPress rejects the save with a message stating exactly what's missing.

🔓 Breached Passwords (PRO)

When a password is created or changed (in the profile, when adding a user or with "Lost your password?"), SeenSecure checks whether it has already appeared in real data breaches and, if so, rejects it: "This password has appeared 23,547 times in data breaches… Choose another one." It uses Have I Been Pwned's public Pwned Passwords service (over 900 million passwords).

• The world's reference service: Have I Been Pwned is built into Firefox (Mozilla Monitor) and the 1Password password manager, and more than 40 governments, such as the UK National Cyber Security Centre (NCSC), Australia and Germany (CERT-Bund), use it to monitor their domains.
• The password never leaves your site (k-anonymity): its SHA-1 hash is computed and only its first 5 characters are sent, shared by hundreds of passwords; the comparison happens on your server and responses are padded so not even their size gives anything away.
• If the service does not respond, the password is allowed: it never blocks anyone because of a third-party outage.
• Options: reject if it appears at least N times (1 = any breached password, recommended) and which roles it applies to (none checked = all).
• Test a password: from the card you can check any password without saving it.

It complements the Password Policies: a password can meet every requirement ("Summer2023!") and still be on the lists used by credential-stuffing attacks. Configure it in Login Security → Password Policies. The service is free and needs no key.

🔧 Troubleshooting

A legitimate user or IP got blocked

Go to Login Security → Active Lockouts: you'll see the full table with the reason, number of attempts, and whether the block is temporary or permanent. Temporary blocks expire on their own; permanent ones each have their own "Unblock" button (with a confirmation step, to prevent accidental unblocks). No need to wait or touch the general configuration to free up a single person.

My team keeps getting locked out while testing login

Check the Event History first: filter by your IP to confirm how many real failed attempts you're generating. If the block comes from a restricted username (reason login_blackname), you're probably testing with a generic test username (admin, test, etc.) — always use a real username for testing. If it's from normal failed attempts, raise the Lockout Threshold or add your IP to the Firewall whitelist so it doesn't count against the limit.

Frequently Asked Questions

Do temporary blocks need me to do anything? No, they expire automatically. Only permanent ones (typically from a restricted username) need manual unblocking from Active Lockouts.

What's the difference between a lockout from failed attempts and one from a restricted username? The first counts normal failed login attempts; the second specifically triggers when someone tries usernames already blocked by default (like "admin"), and its per-IP attempt threshold is configured separately.

Can I see where login attempts are coming from? Yes, the Event History and the detected-attempts summary show the IP, date/time, and country flag for each attempt's origin.

Can Anti Session Hijacking close the session of someone traveling or using a VPN? If the mode is set to "Block", yes — that's its expected behavior: it closes that specific session as soon as it detects a country change, which is exactly what happens when traveling or switching VPNs. It's not a ban: they just need to log in again normally. If you'd rather just get the alert without closing the session, use "Monitor" mode instead.

Does Password Policy affect passwords that already exist? No, it's only checked when creating a new account or actively changing a password. An old password that doesn't meet the current requirements still works to log in until it's changed.

Why isn't it requiring uppercase/number/symbol even though I enabled it? Check that the main Firewall (WAF) is in Protection mode: if it's in Monitor mode or off, the actual requirement is disabled (the on-screen notice keeps showing, but only as guidance).