What Are The User Session Lock Options And How Do They Work?
User Session Lock feature is a part of the User Management module. It helps you to improve the protection of user sessions against theft and unauthorized access. By configuring the session locks options, you can significantly reduce the risk of user session hijacking.
A potential source of user session compromise is theft of an authenticated user session. With WordPress, this can typically happen when a user's computer (or any other local device) has been compromised with malware and the hacker has been able to steal the cookies from the user's device.
By simply stealing these cookies, the hacker can "pretend" to be that user and gain unauthorised access to the WordPress user session.
The options outlined below will help prevent these sorts of attacks by locking the session to particular properties of the session when it was created.
For example, if you lock a session to an IP address, and the session cookies are stolen and re-used, Shield will see that the session is coming from a different location (IP address) and immediately destroy the session - thus nullifying the attack vector altogether.
How the User Session Lock options work
There are 3 options for locking a WordPress user session:
- IP Address
Option: IP Address
This option locks a user session to their original IP address.
If a user logs in from a given location, and then attempts to resume the session from another location, such as home or via a VPN, Shield will destroy the original session to prevent unauthorized access. The user will be logged out and require a fresh user login.
Note: This may pose an issue if your IP address changes frequently. Some ISPs can do this, so you will need to decide if the increase in security is worth the inconvenience of increased logins. If you use a Password manager, for example, such friction is reduced to near-zero.
This option locks a user session to their web browser. The browser's "useragent" is used to determine the browser.
(Note: a user agent is an HTTP request header string that identifies browsers, applications, or operating systems when they connect to a server)
Similar to the IP Address option, if the web browser (or more specifically, the user agent) changes from the original, the session will be destroy and the user will be required to re-login.
An example where the user agent changes, would be if you applied an update of your web browser during your session.
How To Demonstrate Browser/UserAgent Change Example
Sometimes is easier to understand how this works when you demonstrate it for yourself - here we will use an example with the Chrome browser.
Log into your site > right click anywhere on the page > Inspect. The Developer Tools will open up for you.
Then, click on the three dots in the top-right corner > More Tools > "Network conditions" and for User agent, uncheck "User browser default" option.
You can choose a different user agent from the Custom drop-down menu or as an example, you can put this Googlebot's user-agent into the custom field:
Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Press F5 to reload and once you've done this, your user session will be terminated - you'll be logged-out and directed to your login page.
Important: If you decide to switch to this Googlebot's user-agent and you have Fake Web Crawler option enabled in Shield, you might trigger the offense.
If you'd like to test this with Firefox, you can switch your browser's user agent using this add-on here.
When enabled, this option locks a user session to the original request hostname.
This option is less likely to be triggered, but it will prevent access to a WordPress user session if the domain name used to access the site is different.
This might apply if your WordPress site is configured to respond to aliases. That is, your website responds to more than 1 URL. How you might setup your WordPress site to have URL aliases is beyond the scope of this article, but suffice it to say in most circumstances, enabling this option won't cause you any practical issues.
As always, please ensure you test your site for normal and expected operation when you enable any of these options.
Activity Logging for Session Locks
All activities related to the above options will be recorded in your Activity Log.