Super Duper Two-Factor Login

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.

Can I store the one-time codes in my password manager?

Technically yes – any password manager with TOTP support accepts the manual key shown underneath the QR code. We advise against it. Two-factor authentication only works because the two factors live in different places. If your password and your one-time codes sit in the same vault, a single compromised vault hands an attacker both factors at once, and you are back to single-factor security. Keep the second factor on a separate device; a free authenticator app on your phone is enough.

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 rendered in your own browser by a small bundled script, 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.