Title: Login Armor
Author: wpformation
Published: 27. 4. 2026
Last modified: 11. 5. 2026
---
Prohledat pluginy
# Login Armor
Autor: [wpformation](https://profiles.wordpress.org/wpformation/)
[Stáhnout](https://downloads.wordpress.org/plugin/login-armor.2.1.13.zip)
* [Podrobnosti](https://cs.wordpress.org/plugins/login-armor/#description)
* [Hodnocení](https://cs.wordpress.org/plugins/login-armor/#reviews)
* [Instalace](https://cs.wordpress.org/plugins/login-armor/#installation)
* [Vývojáři](https://cs.wordpress.org/plugins/login-armor/#developers)
[Podpora](https://wordpress.org/support/plugin/login-armor/)
## Popis
**Eight security layers. One lightweight plugin. Zero compromise.**
Login Armor is a complete WordPress security stack built for agencies, freelancers
and pros who deliver audit-ready sites. No premium tier, no bundled marketing dashboard,
no telemetry. Every module runs locally, ships with safe defaults, and stays out
of your way.
Stop juggling Wordfence’s bloat, Solid Security’s upsells, and Limit Login Attempts‘
gaps. Login Armor delivers eight independent modules in under one megabyte, with
the discipline of an enterprise plugin and the licensing of free software.
#### Why Login Armor
* **No upsells, ever.** No „premium“ tier, no „Pro“ buttons greyed out in your
admin. Every feature is GPL.
* **No external services to sign up for.** No API keys, no remote dashboards, no
third-party telemetry. Two optional integrations (Have I Been Pwned for breach
detection, Slack/Discord/webhook for notifications) only fire when you explicitly
enable them.
* **Built to be invisible.** Sub-megabyte ZIP, lazy-loaded modules, indexed queries.
The plugin’s footprint stays under 2 ms on a normal login flow.
* **Multisite-aware, PHP 8.1-native.** Network-activate on a fleet, configure per-
site, manage from the shell with a complete WP-CLI command suite.
* **Production-grade defaults.** Every toggle ships with the value an experienced
admin would pick anyway. Zero-config gets you 80 percent of the protection.
#### Eight independent modules
**1. Hide Login** – Replace `wp-login.php` with a custom slug. Anyone hitting the
old URL gets a 404 from your theme – no leakage that WordPress is even installed.
Compatible with multisite, password-protected posts, reverse proxies, and password
recovery flows. The branded pre-activation modal lets you pick or generate the slug
before flipping the switch, and emails it to you so you can’t lock yourself out.
**2. Brute Force Protection** – Cascading lockouts after repeated failed logins.
Locked attackers see a branded 429 landing page with a live countdown. Repeated
lockouts escalate to a 24-hour ban. Lostpassword, register, XML-RPC and the REST
users endpoint are all gated when an IP is locked, so attackers can’t pivot. Subnet
blocking handles distributed attacks. Trusted X-Forwarded-For for sites behind Cloudflare
or a load balancer.
**3. Hardening** – Thirteen one-click toggles across surface reduction, credential
hardening, and request filtering. Disable XML-RPC, the theme/plugin file editor,
the WordPress version exposure (including `?ver=` on assets, even for WP 6.5+ ES
modules), application passwords, author enumeration, and more. Block reserved usernames
with Unicode-confusable detection. Add an invisible login honeypot. Block PHP execution
in uploads and directory listing via atomic-write `.htaccess` rules.
**4. Two-Factor Authentication** – Enterprise-grade 2FA in three flavours: TOTP
via any authenticator app (Google Authenticator, Authy, 1Password, Bitwarden), one-
time codes by email, and printable backup codes. Trusted devices remembered for
thirty days so you only verify once per browser. A recovery flow lets a user reset
their second factor by email when the authenticator is lost, without a support ticket.
Per-role enforcement, configurable grace period, and a session-aware logout.
**5. Detection and Incidents** – A real-time detection engine groups raw events
into six attack patterns: brute force, credential stuffing, distributed scan, post-
compromise activity, lockout cascade, and protocol abuse. Each incident has a drill-
down view with timeline, source IPs, target users, severity, user-agent fingerprint,
and one-click resolution actions (reset password, block subnet, mark resolved).
**6. Activity Log** – Compliance-ready audit trail of admin actions: plugin installs,
settings changes, role updates, user creation, content publishing, theme switches,
2FA enrollment events. Filter, search and export to CSV with configurable retention.
Seven logger domains, all togglable independently.
**7. Login Page Security Headers** – Content-Security-Policy, X-Frame-Options, Permissions-
Policy, Referrer-Policy and X-Content-Type-Options on `wp-login.php` and the lockout
page. Two presets (standard and strict) with an optional CSP report-uri.
**8. Breach Check** – Detect users logging in with a password that appears in public
data breach corpora, using privacy-preserving k-anonymity lookups against Have I
Been Pwned. Only the first 5 hex characters of a SHA-1 prefix leave the server,
the password and full hash never travel. Optional opt-in email lookup against XposedOrNot.
Fail-soft: a HIBP outage never blocks login.
#### Plus
* **Notifications** by email, Slack, Discord, or generic webhook with built-in
SSRF-safe URL validation, severity threshold and rate limiting.
* **WP-CLI command suite** – `wp login-armor reset-slug`, `unblock`, `whitelist`,`
incidents resolve`, `purge-logs`, `2fa reset`, `2fa devices`, `hardening blacklist`.
Full scripted operations and emergency recovery from the shell.
* **Dashboard widget** – at-a-glance protection status from any admin page, with
a 14-day sparkline and the six headline metrics.
#### Built by
Login Armor is built and maintained by [WPFormation](https://wpformation.com/login-armor/),
a French WordPress agency obsessed with sites that are clean, fast, and audit-ready.
We use this plugin on every site we ship.
* [Plugin overview and roadmap](https://wpformation.com/login-armor/)
* [WordPress security guides](https://wpformation.com/securite-wordpress/) on WPFormation
GPL forever. PHP 8.1+. WordPress 6.8+. Zero dependencies.
**Huit couches de securite. Un seul plugin leger. Zero compromis.**
Login Armor est une stack complete de securite WordPress concue pour les agences,
les freelances et les pros qui livrent des sites prets a passer un audit. Pas de
version premium, pas de tableau de bord marketing integre, pas de telemetrie. Chaque
module tourne en local, embarque des reglages par defaut securises, et reste discret.
Fini de jongler entre la lourdeur de Wordfence, les fenetres d’upsell de Solid Security
et les angles morts de Limit Login Attempts. Login Armor regroupe huit modules independants
en moins d’un mega-octet, avec la rigueur d’un plugin entreprise et la licence d’un
logiciel libre.
#### Pourquoi Login Armor
* **Aucun upsell, jamais.** Pas de niveau „premium“, pas de boutons „Pro“ grises
dans votre admin. Tout est en GPL.
* **Aucun service externe a activer.** Pas de cle API, pas de tableau distant,
pas de telemetrie tierce. Les deux integrations optionnelles (Have I Been Pwned
pour la detection de fuites, Slack ou Discord ou webhook pour les notifications)
ne se declenchent que si vous les activez explicitement.
* **Concu pour etre invisible.** ZIP de moins d’un mega, modules charges a la demande,
requetes indexees. L’empreinte sur un flux de connexion normal reste sous 2 ms.
* **Compatible multisite, natif PHP 8.1.** Activation reseau possible sur une flotte,
configuration par site, pilotage depuis la ligne de commande via une suite WP-
CLI complete.
* **Reglages par defaut prets pour la production.** Chaque bascule arrive avec
la valeur qu’un admin experimente choisirait. Sans configuration, vous avez deja
80 % de la protection.
#### Huit modules independants
**1. Masquer la connexion** : remplace `wp-login.php` par une URL personnalisee.
Toute tentative sur l’ancienne URL renvoie une 404 du theme, sans reveler la presence
de WordPress. Compatible multisite, articles proteges par mot de passe, reverse
proxies, et flux de recuperation de mot de passe. La modale de pre-activation vous
laisse choisir ou generer le slug avant d’activer le module, et vous l’envoie par
e-mail pour eviter tout verrouillage.
**2. Protection contre la force brute** : verrouillages en cascade apres plusieurs
echecs. Les attaquants verrouilles voient une page 429 brandee avec un compte a
rebours en direct. Les verrouillages repetes montent a un bannissement de 24 h.
Les pages lostpassword, register, XML-RPC et l’endpoint REST users sont egalement
bloques pour les IPs verrouillees, pour empecher le pivot. Blocage de sous-reseaux
pour les attaques distribuees. Support de X-Forwarded-For pour les sites derriere
Cloudflare ou un load balancer.
**3. Renforcement** : treize bascules en un clic, regroupees en reduction de surface,
durcissement des identifiants et filtrage des requetes. Desactivation de XML-RPC,
de l’editeur de fichiers theme/extension, de l’exposition de la version WordPress(
y compris le `?ver=` sur les assets, meme les modules ES de WP 6.5+), des mots de
passe applicatifs, de l’enumeration des auteurs. Blocage des identifiants reserves
avec detection des homoglyphes Unicode. Pot de miel invisible sur le formulaire
de connexion. Blocage de l’execution PHP dans `wp-content/uploads/` et desactivation
du listing de repertoires via des regles `.htaccess` ecrites en mode atomique.
**4. Authentification a deux facteurs** : 2FA prete pour la production avec trois
methodes : TOTP via n’importe quelle application authenticator (Google Authenticator,
Authy, 1Password, Bitwarden), codes a usage unique par e-mail, codes de secours
imprimables. Appareils de confiance memorises pendant trente jours, vous ne validez
qu’une fois par navigateur. Une procedure de recuperation laisse l’utilisateur reinitialiser
son second facteur par e-mail en cas de perte, sans ouvrir de ticket. Application
par role, periode de grace configurable, et deconnexion qui ferme proprement les
sessions actives.
**5. Detection et incidents** : un moteur en temps reel regroupe les evenements
bruts en six patterns d’attaque : force brute, credential stuffing, scan distribue,
activite post-compromission, cascade de verrouillages et abus protocolaires. Chaque
incident dispose d’une vue detaillee : chronologie, IPs sources, comptes cibles,
severite, empreinte user-agent et actions de resolution en un clic (reinitialisation
de mot de passe, blocage de sous-reseau, marquage resolu).
**6. Journal d’activite** : piste d’audit conforme des actions admin : installations
d’extensions, modifications de reglages, changements de role, creations d’utilisateurs,
publications de contenu, changements de theme, evenements 2FA. Filtrage, recherche
et export CSV avec retention configurable. Sept domaines de loggers, activables
independamment.
**7. En-tetes de securite de la page de connexion** : Content-Security-Policy, X-
Frame-Options, Permissions-Policy, Referrer-Policy et X-Content-Type-Options sur`
wp-login.php` et la page de verrouillage. Deux presets (standard et strict) avec
une option de CSP report-uri.
**8. Detection de fuites** : repere les utilisateurs qui se connectent avec un mot
de passe present dans des fuites publiques, via des recherches preservant la vie
privee (k-anonymat) sur Have I Been Pwned. Seuls les 5 premiers caracteres hexa
d’un prefixe SHA-1 quittent votre serveur ; le mot de passe et le hachage complet
ne sortent jamais. Verification e-mail optionnelle (opt-in, desactivee par defaut)
via XposedOrNot. Fail-soft : une coupure de HIBP ne bloque jamais la connexion.
#### En plus
* **Notifications** par e-mail, Slack, Discord ou webhook generique, avec validation
d’URL anti-SSRF integree, seuil de severite et rate limiting.
* **Suite WP-CLI** complete : `wp login-armor reset-slug`, `unblock`, `whitelist`,`
incidents resolve`, `purge-logs`, `2fa reset`, `2fa devices`, `hardening blacklist`.
Operations scriptees et recuperation d’urgence depuis la ligne de commande.
* **Widget Tableau de bord** : statut de protection en un coup d’oeil depuis n’importe
quelle page admin, avec sparkline 14 jours et six metriques cles.
#### Concu par
Login Armor est concu et maintenu par [WPFormation](https://wpformation.com/login-armor/),
une agence WordPress francaise obsedee par les sites propres, rapides et audit-ready.
On utilise ce plugin sur chaque site qu’on livre.
* [Presentation et roadmap du plugin](https://wpformation.com/login-armor/)
* [Guides securite WordPress](https://wpformation.com/securite-wordpress/) sur
WPFormation
GPL pour toujours. PHP 8.1+. WordPress 6.8+. Zero dependance.
### External Services
#### Webhook Notifications (optional)
When explicitly enabled and configured by the administrator in LoginArmor > Settings
> Notifications, the plugin sends incident data to third-party services via webhooks.
Data sent: incident type, severity level, IP address, target username, event count,
and site URL.
No data is sent unless the administrator actively enables and configures a notification
channel.
* **Slack** – [Terms of Service](https://slack.com/terms-of-service) | [Privacy Policy](https://slack.com/privacy-policy)
* **Discord** – [Terms of Service](https://discord.com/terms) | [Privacy Policy](https://discord.com/privacy)
* **Custom Webhook URL** – User-configured endpoint (administrator’s responsibility)
#### Gravatar (Automattic)
The Activity Log tab uses WordPress core’s `get_avatar()` function to display user
avatars. WordPress may send a hashed email address to [Gravatar](https://gravatar.com/)
servers to retrieve avatar images. This is controlled by Settings > Discussion >
Avatars.
* **Gravatar** – [Automattic Terms of Service](https://automattic.com/tos/) | [Privacy Policy](https://automattic.com/privacy/)
#### Breach Check – Have I Been Pwned (optional)
When the administrator explicitly enables the **Breach Check** module (LoginArmor
> Settings > Breach Check), LoginArmor queries the public Have I Been Pwned Pwned
Passwords API on each successful login and on password changes to detect user passwords
that appear in public data breach corpora.
Data sent: the **first 5 hex characters** of a SHA-1 hash of the password (k-anonymity
lookup). The full password and its full hash never leave the server. The API cannot
determine which password is being checked – it only sees a 5-character prefix that
is mathematically shared with ~500-900 other candidate hashes.
No API key or account is required. The endpoint is free and public.
* **Have I Been Pwned** – [Pwned Passwords privacy statement](https://haveibeenpwned.com/Privacy)
| [Acceptable Use Policy](https://haveibeenpwned.com/AcceptableUse)
#### Breach Check – XposedOrNot (optional email sub-toggle)
When the administrator additionally enables the **Email check** sub-toggle inside
the Breach Check module (off by default), LoginArmor queries the public XposedOrNot
check-email API on new user creation and on email change to detect email addresses
that appear in publicly disclosed data breaches.
Data sent: the user’s email address (URL-encoded) and a plugin-identifying User-
Agent string. This is unavoidable for the lookup – there is no k-anonymity variant
for email breach checks. Because this call transmits an email address to a third
party, it is opt-in and off by default.
No API key or account is required. The endpoint is free and public.
* **XposedOrNot** – [xposedornot.com](https://xposedornot.com/) | [Privacy Policy](https://xposedornot.com/privacy.html)
## Snímky obrazovky
* [[
* Quick tour of all eight modules – Hide Login, Hardening, 2FA setup with QR code,
Incidents drill-down, Activity Log, Events, and Overview dashboard.
* [[
* Overview dashboard – health cards, security pulse, live event tail, threat banner
that surfaces active attacks.
* [[
* Incidents – real-time pattern detection grouped by attack class with severity
and one-click resolution.
* [[
* Incident drill-down – full timeline, user-agent fingerprint, suggested actions,
escalation flag.
* [[
* Events – complete login attempts log with filters and CSV export.
* [[
* Activity Log – admin action audit trail across seven domains, filterable and
exportable.
* [[
* Settings – modular configuration with live security score and a sticky save bar.
* [[
* Hide Login pre-activation modal – pick or generate the secret URL and email it
to yourself before flipping the switch.
* [[
* Hardening – thirteen one-click toggles grouped by surface reduction, credential
hardening, and request filtering.
* [[
* Two-factor authentication setup – QR code for any authenticator app, copy-paste
fallback, and live verification.
* [[
* Breach Check – fully transparent k-anonymity lookups, separate password and email
toggles, opt-in email check disabled by default.
## Instalace
1. Upload the `login-armor` directory to `/wp-content/plugins/`
2. Activate the plugin through the ‚Plugins‘ menu in WordPress
3. Go to LoginArmor in the admin menu to configure
For multisite: Network Activate the plugin to apply it across all sites.
#### Setting up Hide Login
1. Go to LoginArmor > Settings > Hide Login section
2. Enter your desired login slug (e.g., `my-login`)
3. Save settings
4. **Bookmark your new login URL**: you will need it to access your admin
#### Recovering access
If you forget your custom login URL:
* Use the recovery email feature (configurable in settings)
* Connect to your database and delete the `login_armor_hide_slug` row from the `
wp_options` table
* Use WP-CLI: `wp option delete login_armor_hide_slug`
## Nejčastější dotazy
### Will it lock me out of my own site?
No. Hide Login always sends a one-time recovery URL to the admin email. If you lose
the slug, check your inbox. The plugin also honors `wp-cli` fallback so you can
reset anything from SSH.
### Does it slow my site down?
No. Everything is lazy-loaded and indexed. On a normal login flow the extra SQL
cost is under 2 ms.
### Is it compatible with Cloudflare / reverse proxies?
Yes. IP detection honors trusted `X-Forwarded-For` headers; you pick the header
in Settings.
### Does it work with multisite?
Yes, subdomain and subfolder. Each site has its own modules, logs, and thresholds.
### Can I use LoginArmor alongside Wordfence / iThemes Security / Solid Security?
Yes, but disable overlapping modules on one side to avoid double lockouts.
### Where is the data stored?
Three custom tables in your own database: events, incidents, activity. Nothing leaves
your server.
### How do I migrate my configuration?
Settings are plain WordPress options. Export/import via WP-CLI or any standard options-
sync tool.
### Is there a pro version?
Not currently. LoginArmor is fully free and open source. GPL forever.
### Where can I report bugs or request features?
Support forum: [wordpress.org/support/plugin/login-armor/](https://wordpress.org/support/plugin/login-armor/).
## Recenze
Pro tento plugin nejsou žádné recenze.
## Autoři
Login Armor je otevřený software. Následující lidé přispěli k vývoji tohoto pluginu.
Spolupracovníci
* [ wpformation ](https://profiles.wordpress.org/wpformation/)
[Přeložte “Login Armor” do svého jazyka.](https://translate.wordpress.org/projects/wp-plugins/login-armor)
### Zajímá vás vývoj?
[Prohledejte kód](https://plugins.trac.wordpress.org/browser/login-armor/), podívejte
se do [SVN repozitáře](https://plugins.svn.wordpress.org/login-armor/), nebo se
přihlaste k[ odběru protokolu vývoje](https://plugins.trac.wordpress.org/log/login-armor/)
pomocí [RSS](https://plugins.trac.wordpress.org/log/login-armor/?limit=100&mode=stop_on_copy&format=rss).
## Přehled změn
#### 2.1.13
Bug fix release. Fixes a silent 2FA failure on installs whose permalink_structure
does not end with a trailing slash (e.g. `/%postname%`). With 2FA enabled, the verification
challenge after submitting login credentials would disappear and the user would
land back on the login form with no error message. Reported by a user on 2026-05-
11.
* Fix – `PendingCookie::get_path()` no longer appends a trailing slash to the Hide
Login slug. The cookie was set with path `//`, but the trailing-slash normalisation
in `HideLogin::handle_loaded()` would 302 the verify URL to `/?login-armor-
2fa=verify` (no trailing slash) on installs where permalink_structure does not
end with `/`. RFC 6265 §5.1.4 path-match then refused to send the cookie on `/
` because the cookie path `//` is strictly longer than the request
path. `maybe_render_verification` saw `token_data === false` and silently bounced
to the login URL — exactly the „stuck on login page, no error“ symptom. Setting
the cookie path to `/` (no trailing slash) matches `/`, `//`,
and `//...` per RFC 6265 while still rejecting `/XYZ`.
* Internal – Strictly neutral on installs with trailing-slash permalinks (the V2.1.0-
V2.1.12 majority). No security or functional change for those installs.
#### 2.1.12
Bug fix release. Fixes broken-CSS rendering on the login page when both apex and`
www` hostnames route to the same WordPress without a server-level canonical 301 (
common on shared hosting). Two complementary fixes.
* Fix – `HideLogin::intercept_request()` now canonicalises the request host before
any URI rewriting. If the request lands on a hostname that matches neither `home_url()`
nor `site_url()` (e.g. `example.com/` when `siteurl` is `https://www.example.
com`), Hide Login issues a 301 to the canonical host preserving the full request
URI. Closes the window where WP core’s `redirect_canonical` (which runs later
on `template_redirect`) was being short-circuited by Hide Login’s `plugins_loaded`
priority 9999 interception. Host-only comparison (not scheme/port) to avoid loop-
redirects on misconfigured reverse-proxy setups. Skips WP-CLI, cron and AJAX
defensively.
* Fix – `LoginHeaders::build_csp()` is now host-aware. Every CSP directive that
governs cross-origin resource loads (`script-src`, `style-src`, `img-src`, `font-
src` strict mode, `connect-src` strict mode, `default-src` strict mode, `form-
action`) emits `'self'` PLUS the parsed origins of `home_url()` AND `site_url()`.
Without this, the previous `'self'`-only policy blocked every `wp_enqueue_style()`-
emitted CSS link whenever the document host differed from the asset host. Defence-
in-depth alongside the canonical-host fix. `base-uri` stays `'self'` — cross-
origin `` is always a security hole.
* Feature – New filter `login_armor_canonical_host_redirect` to skip the V2.1.12
canonical-host 301 when returning false (proxy setups, dev environments, multisite
configs with a third routing hostname). Receives `$http_host`, `$home_host`, `
$site_host`.
* Internal – Strictly neutral on installs where `home_url()` and `site_url()` resolve
to the same single canonical host. Bug reported by Alexandre Puy on `dumouriez.
com` (Dynamixhost / Apache / Debian).
#### 2.1.11
Bug fix release. Fixes a V2.1.9 regression on multisite + domain mapping setups (
where sub-sites are mapped to external domains via WP MU Domain Mapping or native
WP 4.5+).
* Fix – `HideLogin::build_login_url()` is now host-aware: chooses between `home_url()`
and `site_url()` based on the request’s `HTTP_HOST` header, instead of always
returning `site_url()` (V2.1.9/V2.1.10 default). Resolves the case where a subsite
mapped on an external domain would redirect immediately to `/wp-admin/` (404)
when typing the slug, because `site_url()` pointed to the original network path
while the request arrived on the mapped domain. Reported on the WP.org support
forum by @graphandco. Standard installs (`siteurl == home`) and multisite headless
setups (where the request arrives on the siteurl host) continue to work as in
V2.1.9/V2.1.10.
* Fix – Slug detection in `intercept_request()` now matches against BOTH `home_url(
$slug, 'relative')` AND `site_url($slug, 'relative')` (instead of just one).
Same dual-base matching extended to the `wp-login.php` and `wp-register.php`
traps. No security change: relative paths only, no new hostnames accepted.
* Internal – Filter `login_armor_login_url_base` (introduced in V2.1.9) is unchanged
and continues to wrap the final URL for advanced overrides (third-host scenarios,
custom subdomain mapping plugins).
#### 2.1.10
Cosmetic fix release. The 404 page served when an anonymous visitor hits `/wp-admin/`
with Hide Login enabled now renders as a proper WordPress 404 instead of a half-
bootstrapped theme page with a duplicated header.
* Fix – `block_access()` now routes through `serve_404_template()` so the response
carries the proper `WP_Query::set_404()` state. Visible effect: body class `error404`
is set, Yoast (or any SEO plugin) emits ``, the theme renders its real 404 template instead of a default page layout,
and themes with sticky headers (Astra Pro, many FSE themes) no longer show a
duplicated header. No security change, no functional change for the actual 404
status header (still 404).
* Internal – 30 lines of duplicated 404 rendering code removed from `block_access()`;
both code paths now share `serve_404_template()`.
#### 2.1.9
Bug fix release. Hide Login now uses `site_url()` instead of `home_url()` to build
the rewritten login URL, matching what WordPress core does inside `wp_login_url()`.
* Fix – Hide Login URL base switched from `home_url()` to `site_url()` (14 callsites
migrated to a new public static helper `HideLogin::build_login_url()`). Inherited
from the WPS Hide Login fork, the previous `home_url()` base was invisible on
the ~99 percent of installs where `siteurl == home`, but broke silently on multisite
headless (siteurl on `admin.example.com`, home on `example.com`), WordPress installed
in a subdirectory (`/wp/`), and reverse-proxy installs with `WP_HOME` not equal
to `WP_SITEURL`. Reported on the WP.org support forum by @graphandco.
* Feature – New filter `login_armor_login_url_base` for exotic setups where neither`
home_url()` nor `site_url()` matches the hostname that actually serves the login
slug (third hostname behind a reverse-proxy, subdomain mapping plugin rewriting
the admin URL, etc.). Receives `$url`, `$path`, `$scheme`, `$slug`.
* Internal – Strictly neutral on the standard install where `siteurl == home`.
Fresh-install, multisite-headless and WP-in-subdir validation suite passed before
tag.
#### 2.1.8
Hygiene release issued from a full V2.1.7 audit. Three findings, all LOW severity,
batched in a single update.
* Fix – `admin/views/tabs/settings.php` queries the V2.1.1 webhook queue table
without an existence guard. On a fresh install where the Activity Log module
was never enabled (table not created) or after `wp plugin install --force` (which
doesn’t re-fire activation), every Settings tab load emitted three DB warnings
in `debug.log` (`Table 'X.wp_login_armor_webhook_queue' doesn't exist`). Non-
fatal but log-polluting. Now wraps the SELECT in a `SHOW TABLES LIKE` guard and
returns zero counts when the table is absent.
* Fix – `uninstall.php` cleanup list was missing the `login_armor_lockout_window`
option (default 24h, used by `LimitLogin::trigger_lockout()` for escalation tracking).
Plugin deletion previously left this single option behind. Now: zero residue.
* i18n – Five untranslated strings surfaced by `wp i18n make-pot` regen: the V2.1.1
Activity Log integrity badge `BROKEN`, the legacy-rows-not-covered amber notice(
singular form), the Breach Check password-found message (singular), the Breach
Check email-breach message (singular), and the plugin description meta. All translated
to French in `languages/login-armor-fr_FR.po`, no em dash. `.mo` recompiled. `.
pot` regenerated against the full source tree (1010 strings vs 990 in 2.1.7)
to capture 20 strings that had been added to the code (V2.1.1 webhook + integrity
UI) but never made it into the translation template.
#### 2.1.7
Preventive release on the Email 2FA enrollment flow. Closes a self-lockout pattern
reported by a user whose hosting silently dropped outgoing mail.
* Fix – Email 2FA enrollment no longer half-commits when `wp_mail()` fails. The`
login_armor_2fa_method = email` user meta was previously written before the verification
email was attempted, leaving a partially configured state behind on hosts where
SMTP is broken (Wanadoo, mutualised hosts without SMTP relay, etc.). The order
is now: send first, persist only on success.
* Feature – New pre-activation modal on the user profile page when a user clicks„
Set up Email“ 2FA. Forces a real `wp_mail()` round-trip with a Send-test-email
button and a safety-net checkbox („I have a second admin tab open“) before the
Enable button unlocks. Both gates must pass, eliminating the most common cause
of admin-locked-out support tickets.
* Internal – New AJAX endpoint `login_armor_2fa_email_test` (nonce-protected) sends
a one-shot test message without consuming the OTP cooldown.
#### 2.1.6
Preventive release bundling V2.1.5 + post-tag cleanup findings. No bug observed
in production — eliminates a latent V2.1.3-style fatal risk in the TwoFactor module
and finishes the uninstall.php cleanup audit.
* Preventive – TwoFactor module now follows the always-require pattern (same as
Activity Log V2.1.4 and BreachCheck). Class files are loaded unconditionally
so any future hook callback that statically references TwoFactor classes survives
fresh installs. Constructor and `register()` still gated by the enable option—
zero-overhead contract preserved.
* Cleanup – `uninstall.php` now drops the V2.1.1 webhook queue table, deletes 14
leftover options (HSTS, login headers preset, activity auto-verify daily, V2.1.1
chain init flag + show-notice, 5 webhook), generalizes the transient SQL DELETE
to `login_armor_*` (covering chain_verify_last and any future transient), and
clears 3 V2.1.1 cron hooks (webhook dispatch + chain repair + chain auto-verify).
Plugin deletion now leaves zero residual data.
* UX – Activity Log Integrity panel now surfaces „X rows before the integrity chain
are not covered by Verify“ when legacy or pre-init rows exist. The verify-chain
coverage scope is now explicit rather than implicit.
#### 2.1.4
Critical hotfix.
* Fix – Fatal error `Class "LoginArmor\ActivityLog\ActivityLog" not found` on every
fresh install. The class file was loaded only when the Activity Log module was
enabled, but the V2.1.1 chain initializer hooked at `init` priority 5 references
the class unconditionally. On a fresh install (Activity Log option not yet set),
every request to `wp-login.php` and the front end crashed with a 500. Existing
sites that already had Activity Log enabled were unaffected. Fixed by always
loading the class file (constructor still gated — zero-overhead contract preserved)
and adding a defensive `class_exists` guard at the top of `maybe_initialize_activity_chain()`.
#### 2.1.3
Critical hotfix.
* Fix – Hardening „Hide WordPress version“ toggle was stripping the `?ver=` cache-
buster from LoginArmor’s own admin assets (admin.css, admin.js), in addition
to WP core and 3rd-party plugin files. Combined with hosting providers that run
a server-side static cache (LiteSpeed LSADC on o2switch PowerBoost, Cloudflare
full-page cache, hosting CDNs) keyed on the canonical URL, every LoginArmor update
past 2.1.0 was invisible to admins for up to a year of cache TTL — the browser
kept fetching the old admin.css from the server-side cache because `admin.css`(
no query) and `admin.css?ver=2.1.2` are different cache keys. Filter now whitelists`/
plugins/login-armor/` paths so our own assets always carry their version-derived
hash, while WP core and 3rd-party version disclosure are still stripped.
* Fix – Defense-in-depth `width="18" height="18"` HTML attributes on the Activity
Log Integrity bar’s shield SVG icon. Without these, if admin.css fails to reach
the browser for any reason (CDN edge stale cache, content-blocker, proxy stripping
CSS), the icon defaults to its intrinsic 300x150px and dominates the page layout.
The CSS rule is still authoritative; HTML attrs are belt-and-suspenders.
#### 2.1.2
Critical hotfix + UX polish.
* Fix – Settings tab fatal error on fresh installs that have not yet enabled the
Activity Log module. The class `LoginArmor\ActivityLog\WebhookDispatcher` was
referenced in the Settings tab without an explicit `require_once`, and the file
is only loaded when Activity Log is on. Visiting the Settings tab on a default
install crashed with `Class "LoginArmor\ActivityLog\WebhookDispatcher" not found`.
Fixed by loading the file unconditionally before its first use.
* Fix – Save-confirmation toast (`Settings saved.`) was anchored top-right and
overlapped the LoginArmor admin tabs nav, making the message unreadable behind
the dark Réglages tab. Moved to bottom-right (Gutenberg snackbar convention),
bumped z-index above sticky elements, and re-tuned the entrance animation to
slide up from the bottom edge.
#### 2.1.1
* Feature – Activity Log integrity: every row is HMAC-SHA256 signed and chained
to the previous one. Detects any direct-SQL tampering, deletion or insertion.
First-in-market for WP audit-log plugins.
* Feature – Signed webhook forwarding: optional async POST of every activity event
to your SIEM, Slack, Datadog, Discord or any HTTPS receiver. `X-LoginArmor-Signature`
HMAC header, adaptive retry policy, max 5 attempts.
* Feature – WP-CLI command `wp login-armor activity verify-chain` for scheduled
audits and orphan repair (`--from`, `--to`, `--repair-orphans`, `--format`, `--
verbose`).
* Feature – Admin UI: new compact „Activity Log Integrity“ status bar in Activity
tab + full Webhook configuration panel in Settings (URL, secret regenerate, send
test event, queue stats).
* Feature – Login Page Security Headers (CSP + X-Frame + Referrer-Policy) now ON
by default on fresh installs; REST public-namespace allowlist filterable via `
login_armor_rest_public_namespaces`; auto-detection of 6 conflicting Hide Login
plugins (Rename wp-login.php, WPS Hide Login, Defender, Solid Security, Wordfence,
AIOS).
* Fix – Hardening: `mask_login_errors` no longer leaks remaining-attempt hint through
LimitLogin filter (S-9), Honeypot switched to `` to survive
theme stripping (S-22), User-Agent truncation cap reduced 500 -> 256 chars (S-
19).
#### 2.1.0
* Security (HIGH) – 2FA pending-verification token no longer travels in the URL.
After the password step, the partially-authenticated session is held in a HttpOnly
+ SameSite=Strict cookie scoped to the login slug, signed with HMAC-SHA256 over`
wp_salt('auth')`. Closes a leak surface that exposed the token via browser history,
server access logs and the `Referer` header.
* Security (defense-in-depth) – The transient that backs the pending session is
now keyed on `sha256(token)` instead of the clear token. The clear token never
appears in `wp_options.option_name` either – DB-read attacks no longer yield
a replayable token.
* Compat – URL token is still accepted as a fallback for one minor (V2.1.0). V2.2.0
will remove the fallback. Browsers that reject SameSite=Strict cookies fall through
gracefully.
* Internal – One-shot upgrade hook purges any leftover V2.0.x 2FA pending transients
from `wp_options` on first load. Idempotent.
#### 2.0.5
Security audit pass. Five fixes identified by an internal Phase 1 + Phase 2 audit
against 2.0.4, each double-checked on production before patching. No functional
regression.
* Fix (HIGH) – REST author-enumeration scope. The Hardening „Disable author enumeration“
toggle now also gates `/wp-json/oembed/1.0/embed`, the `_embed=1` fanout on `/
wp/v2/posts`, and `wp-sitemap-users-N.xml`. The lockout-side REST gate also denies
oEmbed for locked IPs.
* Fix (HIGH) – Optional HSTS header for the Login Headers module. Off by default;
opt-in 180-day or 1-year-with-subdomains modes. Only emitted on HTTPS requests.
* Fix (MED) – IPv6 subnet derivation. `subnet_of()` and `Detection\Classifier::
compute_subnet()` now produce a re-parseable canonical /64 from compressed IPv6(`
2001:db8::1` `2001:db8:0:0::/64`). Subnet block rules entered against IPv6 attackers
now match.
* Fix (MED) – Self-DoS via `0.0.0.0` placeholder. `record_failed_attempt()` and`
check_lockout()` skip the literal placeholder returned by `get_client_ip()` when
the configured proxy header is misconfigured. Prevents site-wide lockout on the
shared placeholder.
* Fix (MED) – „Block PHP in uploads“ toggle off no longer wipes user-authored .
htaccess rules. Only the LoginArmor block (recognized by `# BEGIN/END LoginArmor`
markers, with a legacy fallback) is stripped.
#### 2.0.4
Real fix for the lockout 429 page never appearing on hosts with a public page cache
fronting the Hide Login slug.
* Fix – `LockoutPage::render_on_trigger` now performs a 302 redirect to `/[hide-
slug]/?_la_locked=`. The unique query string defeats every public
page cache (LiteSpeed Cache, WP Rocket, Cloudflare full-page, hosting reverse-
proxy). Verified live with Playwright Firefox 150 + httpx HTTP/2.
* Fix – Branded lockout page logo now appears (path was referencing a file that
did not ship).
#### 2.0.3
Same-day hotfix on top of 2.0.2 for HTTP/2 stream termination.
* Fix – `LoginArmor::flush_response_and_exit()` now mirrors WordPress core’s `_default_wp_die_handler`
exactly (no `fastcgi_finish_request`). Under LiteSpeed/LSAPI, calling `fastcgi_finish_request()`
after a 4xx with a custom body left HTTP/2 streams without END_STREAM, hanging
Firefox/Chromium. HTTP/2 lockout response now arrives complete in 1.3 s.
#### 2.0.2
Critical fix for the lockout 429 page.
* Fix – The branded 429 lockout page now actually reaches the browser when the
lockout is triggered. Root cause: PHP’s default output buffer (`output_buffering
=4096` on most managed hosts) was capturing the body. `LoginArmor::flush_response_and_exit()`
now discards every parent buffer before writing the response. Same helper is
used by Hide Login’s 404 renderer and Hardening’s XML-RPC + access-denied responses,
so all three paths inherit the fix.
#### 2.0.1
Post-launch patch.
* Fix – Branded 429 lockout landing page is now rendered on the lockout-triggering
attempt (#N), not the next one. New action `login_armor_lockout_triggered` fires
after the lockout marker is committed; LockoutPage subscribes and renders inline.
* Feature – Two new „Reset“ buttons in Settings: „Reset all events & incidents“
wipes the events feed, brute-force counters, and incidents in one click; „Reset
all activity entries“ wipes the admin-action audit trail. Both are confirmation-
gated.
* Assets – WordPress.org banner and icon replaced with the navy-blue / yellow-padlock
variant matching the in-admin icon.
#### 2.0.0
First WordPress.org public release of the V2 line. Bundles eight independent security
modules in a single sub-megabyte plugin: Hide Login (custom URL slug + branded lockout
page), Brute Force Protection (cascading lockouts, subnet blocking, X-Forwarded-
For), Hardening (13 one-click toggles), Two-Factor Authentication (TOTP + Email
OTP + backup codes + trusted devices + recovery flow), Detection and Incidents (
6 attack patterns), Activity Log (compliance-ready audit trail), Login Page Security
Headers (CSP / X-Frame-Options / Permissions-Policy presets), and Breach Check (
HIBP k-anonymity + opt-in XposedOrNot).
Pre-release security audit:
* Security – Breach Check email lookup is opt-in by default (only the password
lookup is enabled when the module is activated).
* Security – Reserved-username blacklist folds Unicode-to-ASCII before comparison,
so homoglyphs collapse onto the same blacklist entry.
* Security – REST API gating for unauthenticated users now matches public namespaces
by route prefix on the parsed REST path; substring-match query-string bypass
closed.
* Security – „Hide WordPress version“ also strips `?ver=X.Y.Z` from script and
stylesheet URLs at `script_loader_src` priority 9999.
* Security – .htaccess writes (Block PHP in uploads, Disable directory listing)
are atomic via temp file + rename, with admin notice on flush failure.
## Meta
* Verze **2.1.13**
* Poslední aktualizace **před 4 hodiny**
* Aktivních instalací **20+**
* Verze WordPressu ** 6.8 nebo novější **
* Testováno až do WordPressu **6.9.4**
* Verze PHP ** 8.1 nebo novější **
* Jazyk
* [English (US)](https://wordpress.org/plugins/login-armor/)
* Štítků
* [Activity Log](https://cs.wordpress.org/plugins/tags/activity-log/)[Brute Force](https://cs.wordpress.org/plugins/tags/brute-force/)
[hide login](https://cs.wordpress.org/plugins/tags/hide-login/)[limit login](https://cs.wordpress.org/plugins/tags/limit-login/)
[login security](https://cs.wordpress.org/plugins/tags/login-security/)
* [Podrobnosti](https://cs.wordpress.org/plugins/login-armor/advanced/)
## Hodnocení
Zatím nebyly zadány žádné recenze.
[Your review](https://wordpress.org/support/plugin/login-armor/reviews/#new-post)
[Zobrazit všechny recenze](https://wordpress.org/support/plugin/login-armor/reviews/)
## Spolupracovníci
* [ wpformation ](https://profiles.wordpress.org/wpformation/)
## Podpora
Vyřešené problémy během posledních dvou měsíců:
1 z 1
[Fórum podpory](https://wordpress.org/support/plugin/login-armor/)
## Dary
Chtěli byste podpořit vývoj tohoto pluginu?
[ Přispět na tento plugin ](https://wpformation.com)