The newest addition to Really Simple SSL is hardening features. These features will tackle the known and lesser-known weaknesses when running a WordPress website. Hardening features are focused on minimizing risk by removing points of attack. Mostly in disabling features that are not used or limiting access to those who use them. For more information on Hardening Features for WordPress, please read this article.
Hardening Features
Most of these hardening features are self-explainable, but we will pick some to explain the necessity further. If you have questions about a hardening feature that is not mentioned, visit our definitions page.
Prevent exposed login feedback
Did you know the default login page will tell you when an email address or username is correct? Which means anyone trying to log in can proceed with a reset or brute force attack? This is not only textual feedback, but a correct username or email address is saved and will be pre-filled the next time.
Most brute force attacks on login pages are made with the username ‘admin.’ Removing and preventing common usernames is good practice. Most hosting providers can automatically install WordPress, so you can start without the hassle of creating a database and uploading files. However, some automatic installs also create an admin with the username ‘admin.’ This will randomize the username of any known usernames with ‘admin.’ These admins can always log in with their existing email addresses.
Advanced Hardening Features
Advanced Hardening features are Really Simple SSL Pro features because they can be more intrusive in nature. You could, of course, do this manually as well, if needed.
Change debug.log file location.
The debug.log file can contain sensitive information and might aid attackers in further discoveries, for example, server paths, errors, usernames, and even passwords. The debug.log has a standard path for all WordPress websites and is written to a publicly available directory /wp-content/. Changing the location will minimize anyone trying to download through the standard path. The debug.log is now added to a folder with a randomized name and changes the path, which is impossible to guess. If you’re vigilant with the use of the debugging itself, the debug.log is out of reach.
