We at Stoute Web Solutions have been using Fortress Security since it’s launch and have seen just about every option and configuration settings that exist so we’re fairly comfortable with these kinds of modifications to ensure that changes can be made without causing any issues on the site is has been installed on.
Background
Snicco Fortress addresses a crucial gap in WordPress security by tackling persistent and often overlooked threats with a highly focused and resource-efficient approach. While many existing plugins offer broad security solutions, they sometimes compromise in-depth protection and can also unnecessarily drain resources. The current WordPress environment still navigates through several unaddressed security vulnerabilities, such as outdated password hashing and a lack of core Two-Factor Authentication. Fortress emerges as a meticulously tested solution, providing robust, targeted security without the common pitfalls of resource-heavy operations or superficial “security theater” found in some other plugins. In essence, it provides a sturdy, straightforward, and reliable security solution amidst a landscape of pervasive and evolving digital threats.
The modules
Fortress Security is a suite of modules that allow for personalized modifications based on the unique use case of the protected website. Luckily, Snicco has taken care of ensuring that the default implementation will work for just about 99% of WordPress websites in existence, which makes getting things setup super easy. In this guide, we’re going to review the various modules, some commonly asked questions and even cover some customizations that you may need. Of course, any modifications to the core defaults may have adverse reactions to your site and can even remove/reduce your site’s security so please do so with extreme caution.
Authentication
Two-Factor Authentication
Terminology
As you dig deeper into the world of internet security you’ll likely hear many new terms so as we document our guide to Fortress Security, you’ll often see a bunch of abbreviations used. I’ll outline those here to make sure that you are aware of what each of these abbreviations mean before we dive into using them consistently.
- TOTP: A special password that changes after a certain time.
- OTP: A password you can use only once.
- 2FA: A second step to check it’s really you logging in.
Interaction with WordPress core and plugins
When is 2FA Enforced?
Simply put, Fortress’ 2FA is enforced when logging in to your WordPress website. This could be using the wp-login page or when you have a login form on your website.
When WordPress sees a successful authentication from a user, it sends that user to the 2FA page to validate their authorization and properly authenticate the user thus either providing or denying access to the website.
Common things that trigger the 2FA login validation:
- username/password – This is your typical login form
- application passwords – If you connect WordPress to any third-party systems you’ll likely be using one of these.
- custom and or third-party mechanisms – Functions added by plugins, etc.
While this includes a majority of user requests, it is likely that you may run into additional functions that connect to the 2FA authentication process including, but not limited to, HTTP, XML-RPC, REST-API, etc.
Can I change where the 2FA page redirects me after I log in?
The answer here is yes, but it won’t be something you want to attempt without some experience knowing how to read and write code. If you are attempting to redirect logins to a new location the function will attempt to use the “redirect_to” from WordPress core which is just a hidden field on the login forms that a majority of plugins use, the “_wp_http_referer” function, or even “HTTP_REFERER”
Now, if you aren’t using any of those and have coding experience in this area, here is the code snippet that you can use to change the redirection location:
use Snicco\Enterprise\Fortress\Auth\TOTP\Infrastructure\Event\Determining2FARedirectContext;
add_action(Determining2FARedirectContext::class, function (Determining2FARedirectContext $event) :void {
$event->redirect_too = '/some-other-page';
});
Now that you have the code to make these redirections use it was extreme caution as doing this incorrectly will likely cause major issues with your WordPress install.
What about a form that just isn’t working to allow a user to enter in the 2FA code?
In this rare scenario, you’ll actually find it likely that your form is using a AJAX powered model which just means that it doesn’t behave like normal login forms do so you might need to modify how the form handles the 2FA redirection. Luckily if you have some coding experience, you can make these changes fairly easily with the following code snippet. … or if you’re on one of our support plans, just create a ticket and our team will not only add the code snippet, but we’ll test it to make sure everything is working before enabling it on your live website.
use Snicco\Enterprise\Fortress\Auth\TOTP\Infrastructure\Event\RedirectingUserWith2FAEnabled;
add_action(RedirectingUserWith2FAEnabled::class, function (RedirectingUserWith2FAEnabled $event) :void {
$event->turnRedirectIntoWPError();
});
Should I force all admin users to setup 2FA before they can login?
Okay, this is more of a personal preference, but we strongly recommend that anyone who has elevated permissions, editor and above have 2FA setup, configured, and forced on their user account to ensure that no one can add any code to your site that shouldn’t be there. These days it’s far too easy to bypass the email/password requirements and it’s going to become the normal practice to enable 2FA, so you might as well get ahead of the trend.
Requiring users to authenticate with 2FA before they can access the site prevents anyone from gaining access to something they shouldn’t have access to. Some of these include:
- An attacker can’t just delete the TOTP codes and then have access to anything they want.
- An attacker can’t insert new admin users.
- An attacker with a stolen auth cookie can not create sleeper admin users.
- A non-targeted malware can not insert new admin users using
wp_insert_user.
(If an attacker specifically targets your site AND your site has a vulnerability that gives full OS access, it’s game over no matter what).
Why does it redirect me to a dedicated page that asks for the 2FA code?
This is done to make the implementation of the Fortress Security module straightforward and work with most login forms.
This approach boasts top-tier compatibility with WordPress Core and countless plugins, ensuring a smooth login experience for front-end users.
Using an HTTP redirect guarantees functionality across various platforms – whether your site employs WooCommerce, sticks with the default login page, or utilizes a different system altogether.
Contrarily, opting for a JavaScript-based method might hit a snag, failing to accommodate all login forms except the original one. A case in point: WordFence fell into this trap, limiting its 2FA functionality to just the default login page.
Is it possible that a user can login without 2FA?
Unfortunately, it is possible that you may be using a plugin that bypasses the default authentication process and thus will “authenticate” a user without following best practices. Luckily, the plugins that use this method are very rare but they still exist so it’s best to work with an expert in WordPress to ensure that you’re not opening yourself up to potential security issues. … like our team, *wink wink*.
Other Security Features
- Magic Login Links
- Passwords
- Disabling Password Resets for Privileged Users
- Secure Password Hashing
- Password Policies
- Rate Limiting
- Login Throttling
- Password Reset Throttling
- Sessions
- Custom User Session Storage
- Session Management and Security
- Sudo Mode
- Vaults and Pillars
- Vaults
- Pillars
