Title: Super Duper Two-Factor Login
Author: Super Duper Plugins
Published: 1. mai 2026
Last modified: 10. aug 2026
---
Search plugins
# Super Duper Two-Factor Login
By [Super Duper Plugins](https://profiles.wordpress.org/rogerruckstuhl/)
[Download](https://downloads.wordpress.org/plugin/super-duper-two-factor-login.2.6.2.zip)
* [Details](https://et.wordpress.org/plugins/super-duper-two-factor-login/#description)
* [Reviews](https://et.wordpress.org/plugins/super-duper-two-factor-login/#reviews)
* [Installation](https://et.wordpress.org/plugins/super-duper-two-factor-login/#installation)
* [Development](https://et.wordpress.org/plugins/super-duper-two-factor-login/#developers)
[Support](https://wordpress.org/support/plugin/super-duper-two-factor-login/)
## Description
**Super Duper Two-Factor Login** adds robust two-factor authentication to your WordPress
site. Unlike many alternatives, this plugin is completely free – no hidden costs,
no premium tiers, no upsells. Every feature is included from the start.
🇨🇭🇩🇪🇦🇹 _Hinweis für DACH-Nutzer: Plugin und Support sind auf Deutsch (Schweiz/Deutschland/
Österreich) verfügbar. Alle Texte und Einstellungen sind vollständig auf Deutsch
übersetzt._
**Fully translated out of the box** in German (Switzerland, Germany, Austria), English,
French, Spanish, Italian and Dutch – no separate language pack required.
#### PHP 8.2 or higher required (for security reasons)
This plugin requires **PHP 8.2 or higher**. PHP 8.0 and 8.1 have both reached End
of Life and no longer receive security updates – running a 2FA plugin on an unmaintained
PHP version would defeat its purpose. PHP 8.2 lets us use modern security primitives(
immutable configuration, type-safe method handling, strict return contracts) that
make the plugin harder to attack.
**Don’t have PHP 8.2 yet?** Most hosting providers let you switch the PHP version
with a single click in the control panel (Plesk, cPanel, Hostpoint, all-inkl, Cyon,
raidboxes, etc.). It usually takes less than a minute and does not require any downtime.
If in doubt, ask your hoster’s support – they help with PHP upgrades for free.
#### Two Verification Methods
* **TOTP (Authenticator App)** – Works with Google Authenticator, FreeOTP+, Authy,
Microsoft Authenticator, and any TOTP-compatible app. Setup via QR code or manual
key entry.
* **Email** – Receive a 6-digit code via email on every login. No smartphone required.
#### Comprehensive Fallback System
* **10 Backup Codes** – One-time emergency codes in case you lose your phone. Copy,
download, print, or email them to yourself.
* **Administrator Recovery Key** – Each admin receives a personal 32-character
key during setup. Works even when all backup codes are used up.
* **FTP Emergency Recovery (optional, off by default)** – As a last resort, an
empty file created via FTP can switch 2FA off for administrators. The file name
has to contain a secret token that is generated in the settings and shown once(`
wp-content/.sdtfa-recovery-`), and it is only accepted for 15 minutes
after it was created. All administrators are notified by email, both when it
is used and when an invalid file shows up.
#### Enforcement & Trust
* **Role-Based Enforcement** – Require 2FA for administrators, editors, subscribers,
or any role.
* **Grace Period** – Set a deadline so users have time to set up 2FA before enforcement
kicks in.
* **Hard Enforcement** – Without a grace period, users must complete 2FA setup
on the login page before gaining any access.
* **Enforcement Areas** – Choose where to enforce: admin area, WooCommerce account,
checkout, or entire site.
* **Trust This Device** – Users can save their computer so the 2FA code isn’t required
on every login. Configurable duration (1–365 days).
#### Integration
* **WooCommerce** – Adds a “Two-Factor Authentication” tab to the My Account page.
Enforce 2FA for the account area and checkout.
* **Shortcode** – Display the user’s 2FA status anywhere with `[sdtfa_status]`.
* **Setup Reminder** – A dismissable admin notice with a “Set up now” button. No
auto-popups; users open the setup flow only by clicking.
#### Security
* AES-256-GCM encryption for TOTP secrets at rest
* Secure HttpOnly cookies for trusted devices
* Hashed token storage (never stored in plain text)
* No external dependencies – everything runs locally in pure PHP
* No third-party API calls, no tracking, no data collection. The only HTTP request
the plugin ever makes goes to your own site, and only when you click “Run live
test” in the hardening section
#### Privacy & Hardening (optional)
* **Hide user data in REST API** – Replace sensitive user fields (name, slug, link,
avatar) with neutral values for unauthenticated requests. The REST endpoint stays
reachable for SEO and import tools, but anonymous visitors no longer see real
display names. Uses a strict whitelist that automatically drops any extra fields
injected by SEO, page-builder or e-commerce plugins (Yoast, Rank Math, AIOSEO,
Elementor, WooCommerce, …). Example response for an anonymous visitor on `/wp-
json/wp/v2/users/1`:
* {“id”:1,”name”:”Author”,”url”:””,”description”:””,”link”:”https:\/\/example.com\/”,”
slug”:”author”,”avatar_urls”:{}}
* **Block author archives** – Redirect unauthenticated visitors away from `?author
=N` and `/author//` to prevent user enumeration.
* **Disable password reset** – Disable the “Lost your password?” function for administrators
and/or selected roles. Useful when 2FA must be the only authentication path.
* **Users list column** – A clean “SDTFA” column on Users All Users that shows
the real 2FA status (TOTP, Email, or off) and replaces duplicate columns added
by host mu-plugins or other 2FA plugins.
#### Server & File Hardening (optional)
A strong login does not help when a single uploaded file can take over the whole
site. This section closes that path. Every switch is optional and off by default.
* **Block PHP in the uploads folder** – The single most effective measure against
an uploaded web shell: even if a malicious file makes it into `wp-content/uploads/`,
the server refuses to execute it. The plugin writes a managed rule block into
the uploads and upgrade folders and leaves everything else in those files untouched.
A **live test** drops a harmless probe file, requests it over HTTP and tells
you whether your server really refuses to run it – the only way to be sure, and
it covers nginx too, where .htaccess files are silently ignored. Both probe files
are deleted immediately. Ready-made nginx rules are shown for servers without.
htaccess support.
* **Reject dangerous file types** – Uploads of PHP and other server-side scripts
are refused before the file is stored. Every extension segment is checked, so
the classic `photo.php.jpg` trick is caught as well, and files whose name starts
with a dot (`.htaccess`, `.user.ini`) are refused.
* **Protect sensitive files** – Denies public access to `debug.log`, `readme.html`(
which reveals your exact WordPress version), `license.txt`, database dumps, backup
and editor left-overs, `.env`, `.user.ini` and version-control folders such as`.
git`.
* **Block XML-RPC** – `xmlrpc.php` allows hundreds of password guesses in a single
request and is a popular way around login rate limits. It also powers pingback
amplification attacks. The X-Pingback header and the RSD link are removed as
well.
* **Disable the file editor** – Removes the built-in plugin and theme file editors,
the same effect as `DISALLOW_FILE_EDIT`. Anyone who gets hold of an administrator
account can otherwise write PHP straight into your site from the browser.
* **Disable plugin/theme installation** – The same effect as `DISALLOW_FILE_MODS`,
so a stolen administrator account cannot install a backdoor plugin. For sites
that deploy over FTP, Git or a pipeline. Both options use WordPress’ own filters
instead of defining constants, so nothing in your `wp-config.php` is touched
and an existing setting there always wins.
* **File permission report** – Shows the current permissions of `wp-config.php`,`
wp-content`, uploads, plugins and themes next to the recommended values and flags
world-writable paths. This is a report only – the plugin never changes permissions
by itself.
Rules written to the .htaccess in your WordPress root are verified with a request
to your own site afterwards. If your server rejects them, the block is removed again
automatically, so a restrictive server configuration can never take your site offline.
## Screenshots
[⌊Admin notice prompting users to set up 2FA⌉⌊Admin notice prompting users to set
up 2FA⌉[
Admin notice prompting users to set up 2FA
[⌊Setup prompt asking the user to start now or later⌉⌊Setup prompt asking the user
to start now or later⌉[
Setup prompt asking the user to start now or later
[⌊Choosing the authentication method: email or authenticator app⌉⌊Choosing the authentication
method: email or authenticator app⌉[
Choosing the authentication method: email or authenticator app
[⌊App-based authentication – FreeOTP recommended, with download links⌉⌊App-based
authentication – FreeOTP recommended, with download links⌉[
App-based authentication – FreeOTP recommended, with download links
[⌊Email-based authentication⌉⌊Email-based authentication⌉[
Email-based authentication
[⌊Email confirmation step⌉⌊Email confirmation step⌉[
Email confirmation step
[⌊Backup codes – send by email, download, or print⌉⌊Backup codes – send by email,
download, or print⌉[
Backup codes – send by email, download, or print
[⌊Shortcode displaying the 2FA status on any page⌉⌊Shortcode displaying the 2FA
status on any page⌉[
Shortcode displaying the 2FA status on any page
[⌊2FA status on the user's My Account page – inactive⌉⌊2FA status on the user's
My Account page – inactive⌉[
2FA status on the user’s My Account page – inactive
[⌊2FA status on the user's My Account page – active, with the chosen method⌉⌊2FA
status on the user's My Account page – active, with the chosen method⌉[
2FA status on the user’s My Account page – active, with the chosen method
[⌊Backend admin view: per-account 2FA status and the method in use⌉⌊Backend admin
view: per-account 2FA status and the method in use⌉[
Backend admin view: per-account 2FA status and the method in use
[⌊Settings: enforcement reminder, which roles must use 2FA, grace period, enforcement
areas, validation strictness (strict / normal / tolerant), and trusted-device duration⌉⌊
Settings: enforcement reminder, which roles must use 2FA, grace period, enforcement
areas, validation strictness (strict / normal / tolerant), and trusted-device duration⌉[
Settings: enforcement reminder, which roles must use 2FA, grace period, enforcement
areas, validation strictness (strict / normal / tolerant), and trusted-device duration
[⌊Shortcode for embedding the 2FA status indicator on any page⌉⌊Shortcode for embedding
the 2FA status indicator on any page⌉[
Shortcode for embedding the 2FA status indicator on any page
[⌊Privacy & Hardening: hide user data in the REST API and disable password reset
per role⌉⌊Privacy & Hardening: hide user data in the REST API and disable password
reset per role⌉[
Privacy & Hardening: hide user data in the REST API and disable password reset per
role
## Installation
1. Upload the plugin via **Plugins Add New Upload Plugin**, or install it directly
from the WordPress plugin directory.
2. Activate the plugin.
3. Configure the main 2FA settings under **Two-Factor Login** in the admin menu. Optional**
Privacy & Hardening** features (REST user-data masking, author-archive blocking,
password-reset lock-down, users-list status column) are on the same settings page.
4. Optional: open **Server & File Hardening** on the same page, tick “Block PHP in
the uploads folder”, save, and click **Run live test** to confirm your server really
refuses to execute uploaded scripts.
5. Users can set up 2FA from their WordPress profile page or WooCommerce My Account.
## FAQ
### Which authenticator apps are supported?
Any TOTP-compatible app works, including Google Authenticator, FreeOTP+, Authy,
Microsoft Authenticator, and many others. We recommend FreeOTP+ (Android) and FreeOTP(
iOS) as free, open-source options.
### What happens if I lose my phone?
You can log in using one of your 10 backup codes. If those are also gone, administrators
can use their personal recovery key on the login page. As a last resort there is
the FTP emergency file, but it has to be switched on beforehand under Emergency
access – see the question about it further down.
### Can I enforce 2FA for all users?
Yes. Go to Two-Factor Login settings and select which roles must use 2FA. You can
set a grace period with a deadline, or enforce it immediately – users will then
be required to complete 2FA setup on the login page before gaining any access.
### Does this plugin work with WooCommerce?
Yes. It adds a “Two-Factor Authentication” tab to the WooCommerce My Account page.
You can also enforce 2FA for the WooCommerce account area and checkout.
### What is the “Trust this device” feature?
When enabled by the admin, users can check “Save this computer” during login. The
2FA code won’t be required again on that device for the configured number of days.
### Are external services or images used?
No. Everything runs locally. QR codes are generated in PHP, TOTP calculations happen
on the server, and app store badges use local SVG files. No external images, scripts,
or API calls are made. The one HTTP request the plugin can make goes to your own
website: the optional live test in the hardening section requests a probe file from
your own uploads folder to check whether the server executes it. It only runs when
you click the button, and no third party is involved.
### What does “Block PHP in the uploads folder” actually do?
Most break-ins that start with a file upload only become dangerous at the moment
the server executes that file. The uploads folder is meant for images and documents–
there is never a legitimate reason to run PHP in there. The plugin writes a rule
block into `wp-content/uploads/.htaccess` (and the same for `wp-content/upgrade/`)
that tells the server to refuse PHP and other scripts in that directory. Existing
content in those files is preserved; the plugin only manages its own clearly marked
block.
### The live test says “not protected”. What now?
Two common causes. On **nginx**, .htaccess files are ignored entirely – open the“
Rules for nginx” box below the test and add those lines to your server configuration(
or ask your host to). On **Apache**, the directives may be disabled by `AllowOverride`;
your host can enable them or add the rules to the server configuration for you.
In both cases the other options in this section (upload filter, XML-RPC blocking,
file editor, plugin installation) still work, because they do not depend on .htaccess.
### Will the upload filter block files I legitimately need?
It blocks executable server-side scripts – PHP, Perl, Python, shell scripts, ASP,
JSP and similar – plus files whose name starts with a dot. Images, PDFs, videos,
ZIP archives and office documents are unaffected. If your site genuinely needs to
offer one of the blocked types as a download, a developer can adjust the list with
the `sdtfa_blocked_upload_extensions` filter.
### Is it safe to switch on “Disable plugin/theme installation”?
Only if you update your site another way. The option blocks every install, update
and delete through the dashboard – including WordPress core updates, this plugin’s
own updates and automatic security updates. It is the right choice for sites deployed
over FTP, Git or a pipeline, and the wrong choice for a site that relies on the
update button. You can switch it off again in these settings at any time; you are
never locked out of the setting itself.
### How do I remove the rules the plugin wrote?
Switch the matching option off and save – the plugin removes its own block again.
Uninstalling the plugin does the same. If you prefer to do it by hand, delete everything
between `# BEGIN Super Duper Two-Factor Login` and `# END Super Duper Two-Factor
Login` in the affected .htaccess file. Nothing outside those two markers is ever
touched.
### How does the FTP emergency file work, and why is it off by default?
It is the last rung of the recovery ladder, for the case where 2FA, backup codes
and the personal recovery key are all unavailable. Switch it on under **Emergency
access**; the plugin then shows a file name containing a secret token, exactly once.
Note it down and keep it with your recovery key. In an emergency, create an empty
file with that exact name in `wp-content/` via FTP or your hosting file manager,
and 2FA is skipped for administrators for the next 15 minutes.
It is off by default because up to version 2.6.1 the plain existence of a file named`.
sdtfa-recovery` was enough. That turned “an attacker can write a file into wp-content”
into a way past two-factor authentication, without any code execution. The token
in the file name and the 15-minute window close that; leaving the whole mechanism
off closes it completely. If you never switched it on, there is nothing to do.
### Does the plugin change file permissions?
No. The permission report shows what is set and what is recommended, and nothing
else. Changing permissions automatically is a good way to lock a web server out
of its own files on shared hosting, so the plugin leaves that decision – and the
actual chmod – to you or your host.
### What does the “Privacy & Hardening” section do?
It bundles four optional, independently toggleable features that close common WordPress
information-leak and lock-out paths. Hide user data (REST API) replaces sensitive
fields (name, slug, link, avatar) with neutral values for unauthenticated requests,
while keeping the endpoint reachable so SEO and import plugins still work. Block
author archives redirects unauthenticated visitors away from `?author=N` and `/author/
/` to prevent user enumeration. Disable password reset blocks the “Lost your
password?” function for administrators and/or selected roles. The users-list column
adds a clean “SDTFA” status indicator on Users All Users. All four features are
off by default except the users-list column, which is on by default to clean up
duplicate columns from other plugins.
### Why does the Users All Users page show an “SDTFA” column instead of a generic “2FA” one?
Some hosts and other 2FA plugins inject their own “2FA” column on the users list.
When Super Duper Two-Factor Login is installed, those columns can show outdated
or misleading status (for example a red ✗ even though 2FA is configured here). The
plugin replaces them with a single, accurate “SDTFA” column that reads the real
status from this plugin’s own user meta. If you prefer the original column behavior,
you can disable this in the Privacy & Hardening section.
### Will this plugin conflict with other 2FA plugins?
It is not designed to run side-by-side with another active 2FA plugin – two plugins
both intercepting `wp-login.php` will produce unpredictable results. If you are
migrating from another 2FA plugin, deactivate the other one first. The “SDTFA” users-
list column will hide a leftover column from a deactivated plugin only if that plugin
still injects it; in normal cases the foreign column simply disappears with the
foreign plugin.
### Is this plugin really free?
Yes, completely. There is no premium version, no upsells, and no feature restrictions.
All features are available to everyone.
## Reviews
There are no reviews for this plugin.
## Contributors & Developers
“Super Duper Two-Factor Login” is open source software. The following people have
contributed to this plugin.
Contributors
* [ Super Duper Plugins ](https://profiles.wordpress.org/rogerruckstuhl/)
[Translate “Super Duper Two-Factor Login” into your language.](https://translate.wordpress.org/projects/wp-plugins/super-duper-two-factor-login)
### Interested in development?
[Browse the code](https://plugins.trac.wordpress.org/browser/super-duper-two-factor-login/),
check out the [SVN repository](https://plugins.svn.wordpress.org/super-duper-two-factor-login/),
or subscribe to the [development log](https://plugins.trac.wordpress.org/log/super-duper-two-factor-login/)
by [RSS](https://plugins.trac.wordpress.org/log/super-duper-two-factor-login/?limit=100&mode=stop_on_copy&format=rss).
## Changelog
#### 2.6.2 – 10.08.2026
* **Security: the FTP emergency file no longer works just by existing.** Up to
and including 2.6.1, an empty file `wp-content/.sdtfa-recovery` switched two-
factor authentication off for every administrator. Anyone able to write a file
into wp-content could therefore get past 2FA with a stolen administrator password,
without executing a single line of code. Three things changed:
* Off by default. The mechanism now has to be switched on explicitly under Emergency
access, and sites updating from an earlier version have it switched off.
* The file name must contain a secret token that is generated in the settings and
shown exactly once: `wp-content/.sdtfa-recovery-`. Only the hash of that
token is stored, so a leaked database dump does not hand out a working file name.
* The file is only accepted for 15 minutes after it was created. A forgotten file
closes the door again by itself. FTP uploads that preserve the original modification
time are handled correctly, because the inode change time is used when it is
newer.
* New: when a file shows up whose token is wrong or which is too old, all administrators
are notified by email (throttled to once per hour). A rejected file is a strong
hint that somebody can write into your wp-content directory.
* For the record: this always affected the 2FA step only, never the password check–
valid administrator credentials were required in any case, and only accounts
with the actual administrator role were involved.
#### 2.6.1 – 10.08.2026
* Fixed: the two hardening options for the file editor and for plugin/theme installation
no longer define the WordPress constants DISALLOW_FILE_EDIT and DISALLOW_FILE_MODS
themselves. Defining core constants from a plugin pollutes the global namespace,
and Plugin Check rightly flags it. Both options now use WordPress’ own `file_mod_allowed`
filter plus a `map_meta_cap` filter that denies `edit_files`, `edit_plugins`
and `edit_themes`.
* Improved: because filters are evaluated at the moment WordPress needs the answer,
the restriction can no longer be registered “too late” – a constant defined during
plugin load always depends on nothing else having read it earlier.
* Unchanged behavior: the options do exactly what they did before, and a constant
already set in wp-config.php still wins, with the settings screen showing who
is in charge.
* i18n: two reworded option descriptions updated in all eight bundled locales.
#### 2.6.0 – 10.08.2026
* **New section “Server & File Hardening”.** A strong login does not help when
a single uploaded file can take over the site. Six new optional switches close
that path. All of them are off by default and can be enabled independently.
* New: **Block PHP in the uploads folder** – writes a managed rule block into `
wp-content/uploads/.htaccess` and `wp-content/upgrade/.htaccess` so an uploaded
web shell is never executed. Includes a live test that drops a harmless probe
file, requests it over HTTP and reports whether the server really refuses to
run it; both probe files are deleted immediately afterwards. Equivalent nginx
rules are shown for servers without .htaccess support.
* New: **Reject dangerous file types at upload time** – blocks PHP and other server-
side scripts. Every extension segment is checked, so double extensions such as“
photo.php.jpg” are caught as well, and files whose name starts with a dot (.htaccess,.
user.ini) are refused. Adjustable for developers via the `sdtfa_blocked_upload_extensions`
filter.
* New: **Protect sensitive files** – denies public access to debug.log, readme.
html (which reveals the exact WordPress version), license.txt, database dumps,
backup and editor left-overs, .env, .user.ini and version-control folders such
as .git.
* New: **Block XML-RPC** – disables xmlrpc.php, which allows hundreds of password
guesses in a single request and powers pingback amplification attacks. The X-
Pingback header and the RSD link are removed as well.
* New: **Disable the file editor and plugin/theme installation** – sets DISALLOW_FILE_EDIT
and DISALLOW_FILE_MODS without editing wp-config.php. When a constant is already
defined elsewhere, the settings screen says so instead of pretending the checkbox
is in charge.
* New: **File permission report** – lists the current permissions of wp-config.
php, wp-content, uploads, plugins and themes next to the recommended values and
flags world-writable paths. Report only: the plugin never changes permissions
by itself, because an automatic chmod on shared hosting can lock the web server
out of your own files.
* Safety net: rules for the site root .htaccess are verified with a loopback request
right after writing. If the server rejects them (for example because AllowOverride
is restricted), the block is removed again automatically instead of leaving behind
a site that answers with HTTP 500.
* Clean uninstall: uninstalling the plugin also removes the managed rule blocks.
Foreign content and the WordPress rewrite rules in those files stay untouched.
* Internal: new SDTFA_Hardening and SDTFA_Hardening_Admin classes, plus a new `
sdtfa_sanitize_options` filter so modules can own their own settings keys.
#### 2.5.14 – 20.05.2026
* Tested with WordPress 7.0.
* Hardening: REMOTE_ADDR is now passed through sanitize_text_field()/wp_unslash()
before HMAC hashing (Plugin Check compliance, no functional change).
* Code quality: documented Plugin Check false positives with phpcs:ignore markers(
WP_DEBUG-gated error_log calls, nonce-verified AJAX handlers, token-authorized
forced-setup endpoint, SMTP-plugin From-address detection).
* **PHP 8.2 is now the minimum required version.** PHP 8.0 and 8.1 reached End
of Life and no longer receive security patches. Running a 2FA plugin on an unmaintained
PHP version contradicts its purpose. Most hosters allow switching the PHP version
with one click in the control panel.
* Security: brute-force protection for 2FA codes with exponential back-off (30
s 5 min 1 h 24 h) and per user+IP counters. Casual mistypes are unaffected;
sustained guessing is throttled.
* Security: TOTP replay protection – a counter that has been accepted for a successful
login is no longer accepted a second time during its remaining time window (NIST
SP 800-63B §5.1.4).
* Security: encrypted TOTP secrets no longer silently fall back to plaintext storage
if openssl_encrypt fails on the server. The setup flow now surfaces a clear error
so the misconfiguration can be fixed.
* Security: HKDF key derivation for TOTP-secret encryption is now RFC 5869-canonical(
the previous implementation worked but swapped the roles of “info” and “key”
in the expand phase). Legacy ciphertexts written by 2.0–2.5 are still decryptable,
so existing users do not need to re-set up 2FA.
* Security: hard enforcement now also covers the WordPress REST API and Application
Passwords. Authenticated REST requests are rejected for users in an enforced
role who have not yet set up 2FA, and new Application Passwords cannot be created
for those users. (XML-RPC with basic auth was already protected via the standard
wp_authenticate flow.)
* Security: trusted-device cookies now use SameSite=Strict instead of SameSite=
Lax, and are actively invalidated on logout (cookie cleared in the browser AND
server-side token entry removed from user meta).
* Security: email-code cooldown raised from 60 s to 5 min to prevent mail-bombing.
* Privacy: oEmbed responses now neutralize author_name / author_url for anonymous
requests when “Hide user data (REST API)” is enabled.
* Privacy: when “Block author archives” is active, WordPress core’s wp-sitemap.
xml no longer lists the “users” provider – author URLs are not leaked through
the sitemap.
* Internal: new SDTFA_Method enum and SDTFA_Throttle class. Type-safe handling
of 2FA methods (TOTP / Email) and centralized brute-force accounting.
* i18n: 6 new translatable strings for the throttle messages and the openssl error
path. .pot template will be regenerated and locale catalogs updated as part of
the release.
#### 2.5.13 – 13.05.2026
* Fix: Datepicker for the enforcement deadline now opens directly below the input
field instead of at the bottom of the page.
#### 2.5.12 – 11.05.2026
* Improvement: All plugin emails (login code, backup codes, recovery notifications)
are now sent as properly formatted HTML with clear layout, code highlighting,
and per-line backup code display.
* Fix: No longer forces a `From:` header on outgoing emails so SMTP plugins can
apply their SPF/DKIM-aligned sender address without conflict.
* Debug: Added `[SDTFA]` entries to debug.log (when WP_DEBUG is on) to make email-
delivery failures diagnosable.
* i18n: 13 new mail-template strings translated to all eight locales (DE_CH, DE_DE,
DE_AT, EN_US, FR_FR, ES_ES, IT_IT, NL_NL), including a plural form for the validity-
minutes string.
#### 2.5.11 – 05.05.2026
* Fix: WooCommerce `customer-logout` endpoint is now explicitly excluded from 2FA
enforcement so customers can always log out, even when `wc_account` or `entire_site`
enforcement is active.
#### 2.5.9 – 05.05.2026
* Improved: forced 2FA setup screen on wp-login.php now uses larger, more readable
fonts (warning text 16px, button 17px, content 15px) and a slightly wider login
box.
* i18n: translations completed for all eight supported locales (DE_CH, DE_DE, DE_AT,
EN_US, FR_FR, ES_ES, IT_IT, NL_NL) – every string in the plugin is now fully
translated. .pot template regenerated from current source.
#### 2.5.8 – 05.05.2026
* Fixed: forced 2FA setup AJAX calls returned HTTP 403 because the WordPress nonce
check failed for unauthenticated users on the login page. The forced-setup token(
already present in the request and validated against a server-side transient)
is now accepted as the authorization for these AJAX calls, with the standard
nonce check still applied for logged-in users.
#### 2.5.7 – 05.05.2026
* Fixed: forced 2FA setup screen on wp-login.php was unusable – clicking “Set up
now” left the button stuck at “…”. The AJAX endpoints were registered for logged-
in users only, but the forced-setup flow runs before the user is authenticated.
Endpoints now also accept unauthenticated calls when a valid forced-setup token
is supplied, and the JavaScript automatically passes that token along.
#### 2.5.6 – 05.05.2026
* Improved: REST API user-data hiding now uses a strict whitelist approach instead
of a maintained block list. Only structurally-required fields (id, name, slug,
link, avatar_urls, description, url) are kept in the response — everything else
is dropped automatically, including fields from Yoast SEO (yoast_head, yoast_head_json),
Rank Math, AIOSEO, SEOPress, Elementor, WooCommerce, and any future plugins that
inject data into the user REST endpoint.
* New: filter hook `sdtfa_rest_user_allowed_keys` to extend the whitelist for plugins
or sites that have a legitimate need to expose additional public fields.
* Fixed: the filter now runs at priority 999 so it executes after third-party plugins
that register their own user REST fields.
* Fixed: REST self/collection links (which expose the numeric user ID) are now
removed from the response for unauthenticated requests when user-data hiding
is enabled.
* Fixed: “Set up now” button on the admin notice did not open the popup overlay
because the script cached DOM selectors before the popup HTML was rendered. Selectors
are now resolved after DOM-ready, with a fallback redirect to the profile page
if the overlay is still missing.
#### 2.5.5 – 01.05.2026
* Fixed: SVN pre-commit hook on WordPress.org rejected the package because the
email-sending method used a “true” return type (PHP 8.2+ feature). Replaced with
the equivalent “bool” return type for broader compatibility while keeping identical
behavior.
#### 2.5.4 – 30.04.2026
* Fixed: three strings in the en_US translation file contained German text instead
of English (the shortcode description, the deadline notice, and the site-icon
warning). Sites running with English locale will now correctly show English text.
* Fixed: removed remaining German example text from the docblock of the shortcode
class file (no functional impact, source-code cleanup only).
#### 2.5.3 – 30.04.2026
* Fixed: removed remaining hardcoded German strings from PHP source (3× “Nicht
angemeldet.”, backup-codes email body, recovery-key label, backup-codes textarea
header)
* Fixed: removed hardcoded German “Bestätigen” button label from JavaScript (used
after a failed verification attempt) – now uses the existing translatable string
* i18n: all four cleaned-up strings translated for all eight supported locales (
DE_CH/DE/AT, EN, FR, ES, IT, NL)
#### 2.5.2 – 30.04.2026
* Fixed: 2FA setup via email failed silently on hosts that reject mails without
an explicit “From” header – the email now always carries a same-domain sender
address
* Improved: when sending the 2FA code fails, the actual underlying mail error (
from PHPMailer / SMTP) is now surfaced in the setup dialog instead of a generic“
please try again”
* Fixed: send cooldown is now armed only after a successful send, so a failed delivery
no longer blocks the next attempt for 60 seconds
* Improved: graceful fallback for the email subject when the issuer/site name option
is empty
#### 2.5.1 – 30.04.2026
* New: “SDTFA” column on Users All Users showing the actual 2FA status (TOTP /
Email / off) with green check or red ✗
* New: Removes 2FA columns added by foreign 2FA plugins or host mu-plugins to avoid
duplicate or misleading status indicators
* New: Toggle in Privacy & Hardening section to disable the column behavior if
not desired (enabled by default)
#### 2.5.0 – 30.04.2026
* New: Privacy & Hardening section with three optional features
* New: Hide sensitive user data in REST API responses for unauthenticated visitors(
REST endpoint stays reachable for SEO/import tools)
* New: Block author archives (?author=N) for unauthenticated visitors to prevent
user enumeration
* New: Disable WordPress password reset for administrators and/or selected roles
* Fixed: empty jQuery UI datepicker container no longer appears at the bottom of
admin pages – it is now hidden by default and moved next to its input field on
open
#### 2.4.1 – 22.04.2026
* Fixed: dismiss (×) button on the admin notice now correctly persists via AJAX
so the notice doesn’t reappear on every page reload
#### 2.4.0 – 22.04.2026
* Renamed plugin to “Super Duper Two-Factor Login” (slug: super-duper-two-factor-
login) for improved distinctiveness in the plugin directory
* Replaced the setup popup with a WordPress-standard dismissable admin notice and
a “Set up now” button – the modal opens only on user action
* Moved the admin menu from position 3 to position 71 (after Users) to respect
the WordPress admin hierarchy
* Extracted all inline `