Multi-Factor authentication for WordPress login plays an important role in locking-down account access.
Our Shield Security plugin for WordPress has integrated email-based login authentication for several years now. Shortly after this, we added Yubikey authentication. We then added Google Authenticator after that.
This introduced a number User Experience (UX) and design issues because we pushed more login fields into the WordPress login form. This added clutter and confusion for users that hadn’t setup either Yubikey or Google Authenticator.
And, what if we wanted to add another authentication method?
We just had to start again, and so we came up with the Shield Login Authentication Portal. In this article we’re going to outline what it is, and how it works.
What is the Login Authentication Portal (LAP)?
So we wanted to make multi-factor authentication as streamlined as possible, bringing together all the authentication factors into 1 place – Shield’s Login Authentication Portal (LAP).
After a user logins into WordPress we lookup all the login factors that are active on this account. Shield will then present a new independent form to allow the user to enter all the relevant login factors.
It will show only those factors that are active on an account, and nothing more.
This is a huge UX improvement over the previous system where all factors were displayed regardless (this was because on the WordPress login form Shield can never know who is logging in until they actually do so).
Once a user has logged-in and they’re presented with the login portal:
- they have 2 minutes to complete the login process and provide all login authentication factors that are necessary
- depending on the Shield settings, either all, or just 1, of the available authentication factors will be required.
- the logging-in user will not be able to browse to any other page on the site – this includes both the front and back end.
- the user can cancel the login (and be allowed to browse the frontend again) by clicking cancel login, or allowing the timer to expire.
How does LAP work?
When a user logs into WordPress, we allow it to continue as normal. But, we then immediately stop all WordPress loading after authentication.
At the point where WordPress normally recognises a user as being logged-in, we step-in with our Portal and terminate any further WordPress loading.
For the technicians, this stage is the WordPress
init action. Before ‘init’ fires, nothing happens in WordPress using any user permissions. It is just before
init that WordPress authenticates any user logins and reads user WordPress “session” cookies.
And that’s right where LAP jumps in. If a visitor is authenticated with WordPress we grab a hold of that user and determine whether they have gone through the appropriate multi-factor authentication steps.
If they have, we get out of the way. If they haven’t, then Shield steps in and presents the LAP and stops any further WordPress loading.
Once the timeout expires, Shield will logout the user and they’re free to roam again, wherever they please.
Advantages of the LAP
As we alluded to earlier, the Authentication Portal delivers on an improved User eXperience. As the number of options increases for multi-factor login, we felt we had to do something major to improve the WordPress login flow.
We’re considering the addition of further login factors and to do so meant that we couldn’t realistically continue in the manner that we were.
Another great win from the portal is increased compatibility with many 3rd party plugins and systems. There are many plugins out there that are not using the native WordPress login forms and are refusing to also fire the standard, native WordPress hooks. This means that if we rely on using these hooks and other parties don’t use them, then our wonderful multi-factor login functionality just wont work.
With our login portal, users can login using any 3rd party system, and it wont affect us. But, once they’re identified as being logged-in without verification of their account, they’ll be presented with the LAP.
Two-Factor or Multi-Factor?
If you don’t know what this means, please read our article on this and come back here.
Now that you’re up to speed… you can set the Login Portal to either:
- accept just one login factor as sufficient authentication (i.e. two-factor authentication); or
- require all login factors for authentication (multi-factor authentication)
Why would you choose one or the other?
Accept just 1 login factor
- simplicity – 1 factor is just easier all-round
- easier support – users will still be able to login if they lose access to one of their authentication methods
- flexibility – users can use different methods to login depending on circumstances (Yubikey in the office, or Google Authenticator if they have their phone)
Require all login factors
- Increased security through the use of multiple login factors
- You’ll have support issues to deal with if one of your users loses access to one of their login factors
You can enable/disable the Multi-Factor approach using the new option available under Login Protection module > 2-Factor Auth.
The default configuration is to accept just 1 extra login factor, but you are free to tweak this depending on your particular circumstances.
How can you get the SLAP?
We’re rolling out the Authentication Portal with version 5.8.0 of the Shield Security plugin. Once you’re upgraded your plugin, or it does so automatically, you’ll be able to immediately start using it.
Some Common Questions:
- Will the login portal show up in my XML Sitemaps or any other page maps?
Nope. It’s not a page on your site and it’s not something that can ever be linked-to or crawled by a search engine spider.
- What can I do if I lose access to all my authentication factors?
If you’re locked out of your site, then you can always use Shield’s “backdoor” to turn it off.
- I don’t want to use the login portal!
Then you should disable any two-factor authentication options – there are no provisions for continuing to use the WordPress login form for multi-factor information
- Is the authentication portal secure?
It is no more or less secure than the WordPress login form. Ideally you would be using SSL on your site to secure submission of your forms.
- The portal isn’t compatible with my theme/plugin/etc.
Please let us know with as many details as possible.
Comments or Suggestions?
A lot of work has gone into Shield’s Login Authentication Portal based on feedback we’ve received on the current implementation of multi-factor authentication.
We are hopeful that it addresses many concerns and leaves Shield in a great position to adapt and integrate new authentication technologies as the market adapts.
If you have any comments or suggestions for us here, please do leave us a message.
One of your essential plugins
There are some plugins that get installed on every new WordPress site I build, and this is definitely one of them. – It protects your site from brute force login attempts – It screens incoming data to prevent hacking attempts – It prevents spam bots submitting comments on your site…
good so far
I was previously using Wordfence which was causing high IO and Memory usage during its periodic scans which seemed to hang part way through. I’ve no such issue with Shield plugin. I can’t comment on the spam filter as I’m using the alternative, but good that there is no conflicts…
It’s fantastic! Only issue I have is disabling the click-through from the calendar widget event to the actual event on google calendar. Otherwise, it’s great!
Stops the brute-force login attacks, but I need to remove Meta
I especially like the “Rename wp-login.php” feature. *However* it doesn’t remove the login link from the blog. Seems that I have to remove the “Meta” widget myself, so that hackers/bots can’t find the new login page.