WordPress Two-Factor Authentication Ecosystem

A developer-oriented reference for how major WordPress 2FA plugins store secrets, detect users, and validate codes. Useful if you're building a plugin that needs to integrate with an existing 2FA provider -- or if you're evaluating plugins for a project.

You can use this information (and we've provided examples) for writing a simple mu-plugin bridge to connect most 2FA plugins with Sudo for WordPress.

Contents

Document	Description
Ecosystem Survey	How each major plugin stores TOTP keys, detects configured users, and validates codes. Covers 7 plugins with class names, method signatures, and storage details.
Bridge Development Guide	A pattern for building lightweight glue code between a 2FA plugin and any host plugin that delegates 2FA via hooks. Includes a generic three-hook architecture and concrete examples.
Changelog	Project release history and verification-related updates.
bridges/	Drop-in example bridges for WP 2FA (Melapress), Wordfence, and AIOS.

Who This Is For

• Plugin developers who need to verify a user's 2FA status or validate a code programmatically.
• Security auditors comparing how plugins handle secret storage and encryption.
• Site builders evaluating 2FA plugins for compatibility with other tools.

Plugins Covered

Plugin	Active Installs	Bridgeable?	Notes
Two Factor	100,000+	Built-in to many hosts	Provider-based API. The reference implementation.
WP 2FA (Melapress)	90,000+	Yes	TOTP, email, backup codes. AES-256-CTR encrypted secrets.
Wordfence Login Security	5,000,000+	Yes	TOTP only. Singleton class API, custom DB table.
Solid Security	700,000+	Likely automatic	Bundles Two Factor provider classes internally.
All-In-One Security	1,000,000+	Yes	Embeds Simba TFA engine. User meta storage.
Shield Security	40,000+	No	Deeply encapsulated, no public API.
miniOrange Google Authenticator	10,000+	No	Cloud-based validation, no local path.

Known Issues

Two Factor plugin: Silent provider fallback

When a user enables TOTP but the REST API call that saves the secret key fails silently, the Two Factor plugin enters an inconsistent state where TOTP is listed as enabled but no key exists. get_primary_provider_for_user() silently falls back to Backup Codes with no warning. This has been reported upstream as WordPress/two-factor#796.

A related issue -- the profile form allows saving _two_factor_enabled_providers with TOTP listed even when no TOTP key has been validated -- is tracked at WordPress/two-factor#797.

License

This research is released under GPL-2.0-or-later. The example bridge code in bridges/ is also GPL-2.0-or-later.

Contributing

Found an inaccuracy? A plugin updated its internals? PRs and issues welcome. The ecosystem moves fast -- class names and method signatures can change between major versions.

Testing

This repo includes lightweight verification layers:

• PHP lint for the example bridge files.
• WordPress Playground smoke tests that install the real WP 2FA and AIOS plugins from WordPress.org and exercise those example bridges against vendor code, including the WP 2FA backup-code fallback path.
• Vendor compatibility checks that verify the Wordfence bridge still targets real classes and methods present in the current Wordfence plugin package.

Run the Playground smoke test locally:

bash ./scripts/run-playground-smoke.sh

You can also override the WordPress and PHP versions used by Playground:

WP_PLAYGROUND_WP_VERSION=6.8 WP_PLAYGROUND_PHP_VERSION=8.2 bash ./scripts/run-playground-smoke.sh

Continuous Integration

GitHub Actions runs:

• PHP Lint
• Playground Smoke
• Wordfence Bridge Compatibility

The Playground workflow covers a small WordPress/PHP matrix so bridge regressions are checked across more than one runtime combination.