=== Super Duper Two-Factor Login ===
Contributors: rogerruckstuhl
Tags: two-factor, 2fa, authenticator, woocommerce, security
Requires at least: 6.8
Tested up to: 7.0
Requires PHP: 8.2
Stable tag: 2.6.2
License: GPL-2.0-or-later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Free 2FA for WordPress: authenticator app, email codes, backup codes, WooCommerce, role enforcement, plus optional server and upload hardening.

== 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-<TOKEN>`), 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/<slug>/` 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.

== 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.

== Frequently Asked Questions ==

= 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/<slug>/` 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.

== Screenshots ==

1. Admin notice prompting users to set up 2FA
2. Setup prompt asking the user to start now or later
3. Choosing the authentication method: email or authenticator app
4. App-based authentication – FreeOTP recommended, with download links
5. Email-based authentication
6. Email confirmation step
7. Backup codes – send by email, download, or print
8. Shortcode displaying the 2FA status on any page
9. 2FA status on the user's My Account page – inactive
10. 2FA status on the user's My Account page – active, with the chosen method
11. Backend admin view: per-account 2FA status and the method in use
12. Settings: enforcement reminder, which roles must use 2FA, grace period, enforcement areas, validation strictness (strict / normal / tolerant), and trusted-device duration
13. Shortcode for embedding the 2FA status indicator on any page
14. Privacy & Hardening: hide user data in the REST API and disable password reset per role

== 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-<TOKEN>`. 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 `<style>` and `<script>` output into enqueued assets (`wp_enqueue_style`, `wp_enqueue_script`, `wp_add_inline_style`)
* Localized datepicker day and month names via `wp_localize_script` (English source, translations via .po)
* Updated the plugin header description to English (source strings) with German translations moved to .po/.mo
* Corrected the `Contributors` entry in readme.txt to the actual WordPress.org username

= 2.3.0 – 10.04.2026 =
* First public release on WordPress.org
* TOTP and email-based two-factor authentication
* 10 one-time backup codes with copy, download, print, and email
* Personal recovery key for administrators
* FTP emergency recovery via .sdtfa-recovery file
* Trusted device feature (save this computer)
* Role-based enforcement with optional grace period
* Hard enforcement: 2FA setup required before login
* Enforcement areas: admin, WooCommerce account, checkout, entire site
* WooCommerce My Account integration
* Setup popup reminder (dismissible)
* Shortcode [sdtfa_status]
* AES-256-GCM encryption for TOTP secrets
* Translations: German (DE/AT/CH), English, French, Spanish, Italian, Dutch

= 1.0.0 – 2.2.x =
* Internal development and testing

== Upgrade Notice ==

= 2.6.2 =
Security fix: the FTP emergency file no longer disables 2FA just by existing. It is now off by default, its file name must contain a secret token, and it expires after 15 minutes. If you rely on that recovery path, switch it on under Emergency access after updating.

= 2.6.1 =
Compliance fix: the file-editor and plugin-installation options no longer define the WordPress constants DISALLOW_FILE_EDIT and DISALLOW_FILE_MODS themselves. They now use WordPress' own filters instead. Identical behaviour, nothing to change on your side.

= 2.6.0 =
New: Server & File Hardening. Optionally stop PHP from running in the uploads folder, reject dangerous uploads including double extensions, protect sensitive files, block XML-RPC, disable the file editor and review file permissions. All optional, all off by default.

= 2.5.14 =
Compatibility update: tested with WordPress 7.0. Plus minor hardening of REMOTE_ADDR handling and Plugin Check compliance. No functional changes.

= 2.5.9 =
Larger, more readable fonts on the forced setup screen. All translations now 100% complete in all eight supported locales.

= 2.5.8 =
Critical fix continued: forced 2FA setup AJAX returned 403 because of nonce-validation issues for unauthenticated users. Now uses token-based authorization on the login screen.

= 2.5.7 =
Critical fix: forced 2FA setup on the login screen was non-functional. The "Set up now" button now properly opens the setup flow.

= 2.5.6 =
Important fixes: REST API user data is now protected by a strict whitelist (so future SEO/page-builder plugins that add user fields are automatically covered), with a `sdtfa_rest_user_allowed_keys` filter for legitimate exceptions. Also fixed the "Set up now" button on the admin notice.

= 2.5.5 =
Internal compatibility fix that allows the package to pass the WordPress.org SVN pre-commit linter. No functional changes.

= 2.5.4 =
Fixes three strings in the en_US translation that accidentally contained German text. English-locale sites will now show correct English wording on the settings page and notices.

= 2.5.3 =
i18n cleanup: removed remaining hardcoded German strings from PHP and JavaScript so the plugin can be fully translated through the standard gettext workflow.

= 2.5.2 =
Fix: 2FA email codes were silently dropped on hosts that require an explicit "From" header. The setup email now sends reliably and surfaces the real error if delivery still fails.

= 2.5.1 =
New "SDTFA" column on the Users list shows actual 2FA status. Removes duplicate columns added by host mu-plugins or other 2FA plugins.

= 2.5.0 =
New optional Privacy & Hardening features: hide REST user data, block author archive enumeration, disable password reset for admins/roles. Plus a small admin UI fix for the datepicker container.

= 2.4.1 =
Bugfix: the × button on the admin notice now works correctly.

= 2.4.0 =
WordPress.org compliance release: new distinctive name, admin notice instead of auto-popup, proper enqueuing of all assets, corrected menu position.

= 2.3.0 =
First public release. Install and activate to add two-factor authentication to your WordPress site.
