Daniel Convissor

Hi Jason:

Thanks for trying it out again. Actually, the problems you’re seeing now are not the same. The reset password flag was already set from your earlier use.

Beyond that, what LSS thinks is a strong password and what WP thinks is a strong password are two different things. Exactly what did LSS say was wrong with your password? This plugin gives very specific error messages about what’s wrong with a password. What happened when you tried following that messages’ direction?

Guess I need to figure out which filter is used for the password strength indicator and get rid of it.

Thanks,

–Dan

The initial translation work has been put in the 0.22.0 release. Hopefully you’ll have a chance to translate the rest of the stuff.

Roxor:

Thanks for being reasonable. Glad you were thinking ahead with the domain name. I suggest disabling the ability of the general public to create accounts.

There are many tools out there for benchmarking websites to determine what you’ll need in the way of resources. One example is ab (Apache Benchmark). There’s no need to open your site up for public logins.

For the remainder of your testing, you may want to set up some .htaccess or server level rules to only permit access to the site from the IP addresses you (and your associates) are coming in from. Example:

Order deny,allow
Deny from all
Allow from 81.83.1.8

Hi Mike:

The proper permissions for wp-config.php depends on the way your web server works. Most likely, you’ll need chmod 440. This may be, but probably is not, related to the LSS issues you’re encountering.

Can you please read the “The password reset behavior…” passage of the following post:
http://wordpress.org/support/topic/plugin-login-security-solution-password-reset-loop?replies=3#post-3036352. Does that apply to your situation?

I assume you and your client have distinct user accounts and are not sharing them.

What other plugins do you have installed? If there are any others, have you read my plugin’s FAQ? http://wordpress.org/extend/plugins/login-security-solution/faq/

Are you running a stand-alone installation of WordPress, or are you running a multisite network installation?

Are you behind a proxy or load balancer?

Can you dump the contents of your wp_login_security_solution_fail table and email it to me at danielc@analysisandsolutions.com?

As far as reinstallling, just put the plugin files back in place and you should be good to go. WordPress may want you to reactivate it, so check the Plugins page in wp-admin.

–Dan

Hi Mike:

The plugin sets a “change password” flag in each existing user’s metadata. But it does not set a flag for the administrator who presses the button.

Also, you mentioned checking the box. But I didn’t see mention of clicking the button next to it also. Both need to be done for the flag to get set. The two step process helps prevent mistakes.

–Dan

Dean:

Once again, thank you for paying close attention.

My initial thinking was “Yeah, the HTTP_X_FORWARDED_FOR can be forged, but so can the REMOTE_ADDR.” But the underlying point of your statement is that forging an HTTP header is WAY simpler than forging an IP packet or attacking via proxies.

I’ll revert the change and advise users to take appropriate measures.

josediogenes, for the record, my plugin carefully validates all input in order to prevent XSS and SQL vulnerabilities, etc.

Thanks,

–Dan

Hi Jose:

Are you asking in general, or is this a situation you actually have?

I could populate the plugin’s IP data with HTTP_X_FORWARDED_FOR if it’s provided. Sound good?

–Dan

Hi Madhavaji:

Good point. I’ve updated the notice text to specifically state that the link goes to a user interface. The change is in the the 0.21.0 release that has just been put out.

Thanks,

–Dan