Hi @nicomollet Nicolas,
Thanks for the detailed report. A couple of questions that will help narrow this down:
1. Are you using the latest WP 2FA version when this happens? What is your WP Core and PHP version of the website where this happens? Also, is this a single or multisite?
2. When you say the code “changed in your WP backend,” do you mean you can see a different QR code or secret key under your 2FA settings compared to what you originally scanned? Or is it that the code your authenticator app generates is simply being rejected?
We have an article here which teaches the best/most common used apps that we do recommend – in case you are using a different one which is not on the list, let me know.
The reason I ask is that these point to two different causes:
A) If the secret itself changed, the most common reasons are a plugin or WP core update that triggered a reset of your 2FA settings, or a database restore/migration that rolled back the secret to a previous state. Check your activity log if you have one to see if anything happened around the time the codes stopped working.
b) If the secret looks the same but codes are rejected, the most likely cause is server time drift. TOTP codes are time-based and valid only within a narrow window, so if your server clock is even slightly out of sync, codes will consistently fail. You can verify this by checking your server’s NTP sync status, or by asking your host to confirm the server time is correct.
3. A couple of things to try in the meantime:
A) on your authenticator app, look for a “sync” or “correct time” option (Google Authenticator has this under Settings > Time correction for codes). Make sure your site and device are in sync as even a slight mismatch of a couple seconds, can cause this to happen.
B) Also check if the issue happens on all of your websites or just one, as that would help isolate whether it is server-specific. You can also try to check if this happens only with OTP via app, or if it happens with OTP via email as well.
C) One (important) more thing worth checking if you are using a CI/CD pipeline or any kind of git-based deployment: if a deployment pushed a new or different version of your wp-config.php, WP 2FA’s own encryption key may have changed in the proces. We have prepared an article here which teaches best practices to keep the 2FA system intact even in such circumstances.
Let us know what you find and we can go from there.
When you say the code “changed in your WP backend,” do you mean you can see a different QR code or secret key under your 2FA settings compared to what you originally scanned? Or is it that the code your authenticator app generates is simply being rejected?
Thanks for the reply.
We are using WP 2FA Version 3.1.0.
WordPress 6.6.1
PHP 7.4 (yeah… I know)
Looking at your doc https://melapress.com/support/kb/wp-2fa-migrating-plugin-2fa-setup/ I believe a deployment is the cause. Our wp-config.php is versioned. So when we deploy we override the file on the server.
I suppose I need to put WP2FA_ENCRYPT_KEY in my wp-config.php original file to solve the issue.
Thanks I will try that!
Thanks for the update @nicomollet !
Indeed – that seems the case here – make sure you exclude and retain the database WP_2FA entries along with the secret key inside wp-config.php file before each deploy, and make sure they remain intact, otherwise, previous/existing 2FA configuration will be affected.
Just to make it clear – the encrypt key from the article is just an example – and from now on, you need to ensure that you are always using the same encrypt key; the article teaches everything you need to know about the process, long story short, the WP 2FA plugin needs to remain disabled during this process, to avoid unwanted regeneration of it’s encrypt key.
I would also suggest that you update the plugin to the latest 3.1.1.2, just to be sure everything is aligned and that my support to be as relevant as possible.
I hope this helps, and do let me know once you give that a try!
