Early on in our security plugin we introduced email two factor authentication for WordPress users. It’s been a fantastic, yet hugely powerful addition to our WordPress security.
Then, as the plugin developed, we introduced more and more features. One of these was User Session management and since then, things have been a little muddled.
As it turns out, our email-authentication system is actually a user sessions system too. It meant that our plugin now had 2x user sessions sections.
With our release of the Shield Security plugin, v4.17.0, we’ve simplified email authentication. This article will help explain what’s changed and what you should be aware of.
So what’s new?
Up until now, there were 2x ways to turn on email authentication:
- By IP address
- By cookie
What did these mean exactly? Well this is where idea of user “sessions” comes in. When you clicked the link in the email to authenticate, we locked that particular “link” to either your IP address, or a cookie. (or both).
Then each time you loaded a page, we checked that your IP address and/or cookie matched up with your username.
Kinda like a user session, right? Exactly.
But that’s not the role of two-factor authentication. Multi-factor authentication is there solely to verify the identity of the logging-in user.
And that’s what we’ve decided to change – no more psuedo-sessions.
Instead of 2 options to turn of email authentication, you will just have 1 – to turn on email-based authentication.
And that’s it. When you click the link to verify your identity in your email, the plugin checks it and lets you in. After that, no more checking your identity until you try to log in again.
But what if you still want WordPress user sessions in the plugin?
We introduced user session management some time ago. This remains unchanged and you can toggle this under the User Management section.
Not sure why you want user sessions? Our user sessions identify not-only the username, but their IP address. You can’t really fake this.
It is also checks your session on every page load. Anyone that obtains administrator access (somehow) will go through the checks and get booted out if they don’t pass.
What do you need to do?
Actually, you don’t need to do anything. This article is to provide some background information for users that are confused or want to learn more.
We will automatically switch your settings to the new option if you have it running already.
Questions or comments? Let me know below.
Hi! I understand why this made more sense: the previous options may have been a little confusing.
However, I wonder whether it is still possible for users to have to verify by e-mail 2FA if – and only if – they’re trying to log in from a *new* IP address? It seems that, in the new version, they have to verify by e-mail 2FA every single time they log in. It seems there is now no longer a way to save users this trouble, or did I miss something?
The same applies to 2FA by session (another very cool option), I think?
In case I wasn’t clear, here is a quote from the old description of 2FA by IP, which is the way I’d like it to work:
“So, when 2-factor authentication is enabled by IP address, and user attempts to log into their account, the system will ask:
– What is the IP address of the connecting user. (you can find your IP address, for example, by going here)
– It will then look up the database and ask – has this username validated their identity while connected to the site using that IP address?
If the answer is ‘Yes’, then the login will be permitted.
If the answer is ‘No’, login will be temporarily rejected, and an email sent to that user’s registered email address asking them to click a verification link.”