Before this thread gets closed (without a solution), here is some additional feedback.
I’ve been using Wordfence Security’s 2FA on over a dozen websites without any issue whatsoever. All have something in common, though: they run under Linux. Most use nginx, a few are on Apache. All use PHP 7.+ — php-fpm under Linux, mod_php under Apache.
By sheer chance, there is a single exception — for a particular customer I had to install a temporary site with WordPress in their FreeBSD server, which runs Apache 2.4.41 — but PHP 5.6.40. There is a reason for this: they’re in the process of migrating an old CMS, which has been abandoned, but which is barely compatible with PHP 5.6 and not compatible with 7.x at all. (For the sake of completeness, you can check what version your system is running by going to Wordfence > Tools > Diagnostics.) PHP 5.6.40 had to be restored from ancient archives and manually compiled since it has been removed from the FreeBSD repositories.
Anyway, I had the same exact issue as described by the OP (I’ve used Chrome and Safari to test), and first I had to restore access to the back-office. Because it might be helpful for others, here is what I did (remember, this is under Apache; for nginx things are slightly different):
- Go to your WordPress installation’s root directory, open the
.htaccess file, and delete all lines between # Wordfence WAF and # END Wordfence WAF (don’t worry, these will be restored later)
- Now go to
wp-content/plugins/ and remove the wordfence directory entirely (again, don’t worry, since all your settings will be stored on the MySQL database)
- Login back to your back-office — this time you will not get any requests for 2FA, of course
Now at this point I simply reinstalled Wordfence again; Wordfence will behave as if it is a ‘new’ installation — i.e. it will modify the .htaccess as before — but it will get most of your personal settings from the MySQL database, so you should be fine.
In my case, activating 2FA blocked me again — just as before! — so it was clear that something was missing. And it was easy to see what it was: going to Wordfence > Tools > Diagnostics showed that the OpenSSL module had not been found! Wordfence requires OpenSLL to contact its remote servers for the scans (although I believe there is an option to override this; in my case, I just got a warning that the current scan could not be completed because the plugin could not contact the remote servers), and, apparently, so does the 2FA module.
I thought that I had OpenSSL compiled into PHP… but it was easy to confirm that I had totally forgotten to do so! Therefore, all I did was compile that module (in your case you might simply be able to get the appropriate package), reload Apache, reload the Wordfence Diagnostics page — and, this time, it showed that OpenSLL was active. After re-activating 2FA for my user, I could now log in from any browser — even those which had their cookies and cache cleared, and I got the 2FA box every time!
I’d suggest that the OP checks if they have OpenSSL enabled or not because it might be as simple as that…
To the Wordfence developers: while most of your plugin will work without OpenSLL being active, clearly 2FA will fail (without errors on the logs), so I’d suggest that, before allowing users to activate 2FA, you check first if OpenSSL is active or not.
It’s safe to assume that the vast majority of Wordfence users will have PHP 7+ with OpenSSL enabled — which is pretty much the standard these days! — but a few will not…
