nlpro

Hi @sebastienserre,

Navigate to Security > Settings > Advanced > System Tweaks

Disable (if not already) the?Disable PHP in Themes?setting in the?PHP Execution?section. Scroll to the bottom of the page and save the settings.

+++ To prevent any confusion, I’m not SolidWP +++

• This reply was modified 11 months, 2 weeks ago by nlpro.

Hi @wpzugang,

Security >Tools > Server Config Rules –> .htaccess file (Apache config file)

Security >Tools > wp-config.php Rules –> wp-config.php file (WordPress config file)

When you disable the “Write to Files” setting, no Solid Security rules are automatically written to the .htaccess (Apache config file) or wp-config.php (WordPress config file) file. This also means that any Solid Security rules that have been written to these 2 files in the past should automatically be cleared. If that is not the case (for whatever reason) it’s probably best to have clean files (That is, without any SolSec rules) to begin with.

Below I will attempt to give you an overview of how these 2 files are structured once the SolSec rules are manually included. Hopefully this will answer most of your questions. First the .htaccess file (Apache config file):

# BEGIN iThemes Security - Do not modify or remove this line
# iThemes Security Config Details: 2
...
# END iThemes Security - Do not modify or remove this line

# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Where … represents the actual SolSec rules. For clarity’s sake I’m not including the actual rules. Note: The old iThemes Security plugin name is still in use in the SolSec plugin comment lines (These serve as templates that can be used by the plugin code to find stuff). No need for panic. This is probably for backward compatibility reasons (right @shanedelierrr?)

On to the structure of the wp-config.php file (WordPress config file):

<?php

// BEGIN iThemes Security - Do not modify or remove this line
// iThemes Security Config Details: 2
...
// END iThemes Security - Do not modify or remove this line

define( 'ITSEC_ENCRYPTION_KEY', 'Vh9HWGprIEFzXvRZbEk3bzw0MDAsM0spNVJoP4dIVzh+bj5kU1NabC52RjtoamM7M3VLPGlQTllyRTQtQFsoNA==' );

/** 
 * The base configurations of the WordPress.
 *
 * This file has the following configurations: MySQL settings, Table Prefix,
 * Secret Keys, WordPress Language, and ABSPATH. You can find more information by
 * visiting {@link https://codex.www.ads-software.com/Editing_wp-config.php Editing
 * wp-config.php} Codex page. You can get the MySQL settings from your web host.
 *
 * This file is used by the wp-config.php creation script during the
 * installation. You don't have to use the web site, you can just copy this file
 * to "wp-config.php" and fill in the values.
 *
 * @package WordPress
 */
...
/** WordPress absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
	define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

Again I am using … to represent omitted lines that are irrelevant. Note there is a line included outside the SolSec plugin template that defines the ITSEC_ENCRYPTION_KEY constant. One would expect that to be within the SolSec plugin template but (probably for good reasons) it’s not ??

I hope this helps.

Hi @jtphelan,

I noticed you are using TFA as the abbreviation for Two-Factor Authentication. Allthough I think your solution is creative, I just wanted to share that the usual abbreviation is 2FA ??

Hi @richardshea,

If you are convinced you are experiencing the exact same issue that has already been reported, simply click on the existing topics’ Subscribe link and you’ll be notified if there’s a reply.

So indeed (initially) no need to create duplicate topics ??

Hi @shanedelierrr,

This minor bug appears to have been fixed in the Solid Security Basic 9.3.2 release. So marking this topic as “resolved” ??

Hi @pixelconverter,

According to the Why Are Some Features Not Available? entry from the Solid Security FAQs:

…

The simplest option is to choose “Security Check Scan (Recommended)” which causes your site to connect to an API provided by SolidWP. (Note: Users of Solid Security Basic may need to enable “Security Check Pro” at Security > Settings > Features > Utiltities (tab) for this option to appear.)

…

+++ To prevent any confusion, I’m not SolidWP +++

• This reply was modified 1 year ago by nlpro.

Hi?@tiagorodriguesweb,

Ok, I see. Probably best to have a look at the SolSec plugin Logs page. Filter for modules “Local Brute Force” and “lockout”.

Hi @tiagorodriguesweb,

Are you logging in from the mobile phone using the WordPress app or from a browser (Android or Apple iOS)?

Hi @tiagorodriguesweb,

Just attempted 5 logins and I got locked out. So it’s working fine.

Your IP is probably automatically (temporarily) whitelisted because you successfully logged in as an Administrator user to the Admin Dashboard before testing brute force from the same IP.

You cannot see in the Solid Security UI which IPs are automatically (temporarily) whitelisted due to successfull login by an Administrator user. Note such IPs are removed from the whitelist after 24 hours.

Oh, almost forgot to mention. You can disable the temporary whitelist by adding the line below to the wp-config.php file:

define( 'ITSEC_DISABLE_TEMP_WHITELIST', true );

+++ To prevent any confusion, I’m not SolidWP +++

• This reply was modified 1 year ago by nlpro.
• This reply was modified 1 year ago by nlpro.
• This reply was modified 1 year ago by nlpro.

Hi @nuttyhiker,

I do not have any plugins installed that would disable that unless this plugin does that.

Turns out the Solid Security plugin hooks into the wp_is_application_passwords_available_for_user filter when the 2FA feature is enabled … (I was not aware of that).

You have to navigate to Security > Settings > User Groups and, under section Two Factor, enable the Application Passwords toggle for the right group (user(s)).

Hope this finally deals with the issue ??

• This reply was modified 1 year ago by nlpro.
• This reply was modified 1 year ago by nlpro.

Hi @anne1101,

Yes, once the wp-content/languages/plugins/better-wp-security-de_DE.po file is opened in Poedit it will say 837 of 838 (99%) translated (The string “Backup” is missing the plural translation). Don’t be fooled by the 99% because the current German plugin translation is only 39% completed as indicated on translate.wordpress.com. Apparently translation strings submitted but waiting for approval and/or untranslated on translate.wordpress.com are not yet included in the .po file (Learned something new … ). When the translation on translate.wordpress.com is 100% completed the .po file will contain 1761 strings.

It does by the way contain the string “Das Passwort wurde nicht aktualisiert.”(The password has not been updated.)

Since Poedit doesn’t allow you to add a new string use something like Notepad to add the new translation string:

#: core/modules/strong-passwords/Strength_Requirement.php:84

msgid “Due to site rules, a strong password is required. Please choose a new password that rates as Strong on the meter.”
msgstr “”

(There is not supposed to be an empty line between the first and second line but for some reason I can’t get rid of it)

Then use Poedit to add the translation (Aufgrund von Website-Regeln ist ein starkes Passwort für dein Konto erforderlich. Bitte w?hle ein neues Passwort, welches als Stark auf dem Z?hler bewertet wird.) and save the file. Make sure to upload/replace both: .po and .mo files. WordPress only uses the .mo file.

• This reply was modified 1 year ago by nlpro.
• This reply was modified 1 year ago by nlpro.
• This reply was modified 1 year ago by nlpro.

Hi @anne1101,

The shortest route would be to edit the wp-content/languages/plugins/better-wp-security-de_DE.po file (which is probably already there) using Poedit. Then simply add the German translation string and save the file.

The longer route is to get the currently submitted translation string approved on translate.www.ads-software.com. It’s current status is waiting for approval. Once it’s approved you only need to update the German plugin translation in the site.

+++ To prevent any confusion, I’m not SolidWP +++

Ok, switched from the iPad to my laptop ??

So the only way to get a true value returned is the last option, the wp_is_application_passwords_available_for_user filter. Note the filter defaults to a true value. This is because by default all users can make use of application passwords.

Conclusion is that you have to get passed 2 conditions to reach the filter that is the only chance for returning a true value. On a site with a SSL cert installed, odds are against the Application Passwords section getting rendered ??

• This reply was modified 1 year ago by nlpro.
• This reply was modified 1 year ago by nlpro.

Hi @nuttyhiker,

Ok, so let’s break this down. There are 2 conditions which when met will cause the beginning of the Application Password section to get rendered. Since there is nothing related to Application Passwords rendered both conditions are not met. Let’s start with the easy one, the second condition:

! wp_is_application_passwords_supported();
// Equals:
// false === wp_is_application_passwords_supported();

Since your site has a SSL cert installed this function returns true. So indeed this condition is not met.

So that means to get the beginning of the Application Password section rendered, the first condition must be met:

wp_is_application_passwords_available_for_user( $user_id );
// Equals:
// true === wp_is_application_passwords_available_for_user( $user_id );

This function starts with 3 conditions and ends with a filter:

if ( ! wp_is_application_passwords_available() ) {
	return false;
}

if ( ! is_object( $user ) ) {
	$user = get_userdata( $user );
}

if ( ! $user || ! $user->exists() ) {
	return false;
}

return apply_filters( 'wp_is_application_passwords_available_for_user', true, $user );

When the first or third condition is met, a boolean false value is returned. So one of these conditions may evaluate to true, return a false value and thus cause the Application Passwords section not to render. The first condition is:

! wp_is_application_passwords_available();
// Equals:
// false === wp_is_application_passwords_available();

Since the site has a SSL cert installed this function returns true. So this condition is not met.

The third condition checks the user data. Basically if the user data is invalid the third condition evaluates to true and a false value is returned.

Since my iPad battery is running out of juice I’ll save this post now and continue in another post …

• This reply was modified 1 year ago by nlpro.
• This reply was modified 1 year ago by nlpro.
• This reply was modified 1 year ago by nlpro.

Hi @nuttyhiker,

The Application Passwords feature was initially made available as a plugin, but ever since the release of WordPress 5.6 it is part of WordPress Core.

The UI rendering of the Application Passwords feature in the user profile page starts at line #767 ( WordPress 6.4.3) of the wp-admin/user-edit.php file with:

<?php if ( wp_is_application_passwords_available_for_user( $user_id ) || ! wp_is_application_passwords_supported() ) : ?>