[Plugin: Login Security Solution] https and multisite problems

Hi Jason:

Sorry you’re having problems. My only hunch at this point is something to do with auth cookies. I’ll need your help pinpointing the issue.

Go into my class’ log() method. Adjust the path to the file as needed. Then in my auth_cookie_bad() method, add this call on the first line: $this->log("auth cookie bad."); You can also uncomment the pre-existing log calls in the file too.

Then use the site while monitoring the log file. Make notes of what you do and what shows up in the log file.

Thanks,

–Dan

Hi Jason: I want to roll a new release in the near future. Can you please provide the requested feedback? Thanks, –Dan

Hi Daniel,

I’ve been very busy the last few weeks and haven’t had a chance to do the things you asked yet.

I’ll try and give it a go this weekend.

Thanks,

Jason

Hi Jason:

There are some changes in 0.22.0 that will probably take care of the problems you were having.

–Dan

Hi Dan,

Thanks for the update. I tried it and got the same problem immediately.

It asked me to do the reset-password procedure. when I clicked on the link sent to my email, it asked me to type in a new password. when I type in the new password and hit return it says that it was not strong enough and asks me to do it again. even though the strength indicator was “strong” before I hit enter.

I can try some debugging again if you like. or maybe you could provide a debug enabled version I could try?

Jason

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

Gah. There is no simple way to override the strength indicator.

Hi Dan:

Please remember that the password strength meter is only an indicator, there is no problem in my opinion of later reporting on submission that the password wasn’t good enough. Some things can only be checked at that point in time, or don’t make sense to check immediately – i.e. password is the same as a previously used password.

If you still find the need to adjust it…

I would not recommend removing the password strength meter… however you should be able to replace the use of the JavaScript file which will override the display of the messages.

1) Remove the use of the existing JavaScript file.

wp_deregister_script( 'password-strength-meter' );

2) Replace it with your version, so take a copy of /wp-admin/js/password-strength-meter.dev.js and place it in the plugin folder… Register your script as a replacement …

wp_register_script( 'password-strength-meter', ... );

3) Localize any of your strings.

wp_localize_script(( 'password-strength-meter', 'pwsL10n', array(
		'empty' => __('Strength indicator'),
		'short' => __('Very weak'),
		'bad' => __('Weak'),
		/* translators: password strength */
		'good' => _x('Medium', 'password strength'),
		'strong' => __('Strong'),
		'mismatch' => __('Mismatch')
	) );

4) Check your script is being used in the appropriate pages – it should be because you used the same handle password-strength-meter.

Hope this helps,
Cheers,
Dean

When hitting “post” I thought, “I bet Dean will have something to say about this.” I’ll have to look into that. Thanks!

Hi Daniel,

Thanks for following this up. It appears that I was just too hasty. I re-enabled the plugin and set a password that matched the requirements listed. Namely at least 20 characters long.

Logged in fine with new password and all seems to be working well.

Thanks again and apologies for the noise.

Jason

Hey Dean:

Why would you “not recommend removing the password strength meter…”?

Thanks,

–Dan

I went ahead and removed the password strength indicator in the new release, 0.24.0.

Dean, I’m still curious to hear your thoughts when you get a chance.

Hi Dan:

Actually I did respond to your post, a rather lengthy response at that…
… I even edited it a couple of times to correct formatting.

However it seems that somehow it seems to be removed – perhaps treated as spam because of the multiple reference links I included.
Looking through my history all I can find is the post ID (#3111201) – no content.

In short, some of the largest company’s include password strength indicators:

• Google (with all their user experience research, even down to one pixel movements)
  Reference: https://googleblog.blogspot.co.uk/2008/11/art-of-field-study.html
  Google handles 100’s of millions of users.
• Apple majority of users with credit card attached because it’s the defacto thing to do when purchasing Apps (even free ones) via the App Store.
  Check Apple’s password strength indicator out: https://dl.dropbox.com/s/uqh12xba3fvqjir/2012082701%20-%20Apple%20Password%20Change%20Indicator.PNG
• Microsoft
• Many more to go here – however I don’t want to get the post blocked for too many links:
  Let me leave you with too reference posts:
  https://designinginterfaces.com/patterns/password-strength-meter/
  And because the site is down a Google Cache link to UI-Patterns:

Rationale
By showing a password strength meter beside the password field, the user is forced to consider using a password with an appropriate strength. By putting a minimum level of password strength you can even use the password strength meter to force a heightened security to your website.

Using a password strength indicator on the website, another level of security is added to the site. This not only makes the current users of the site feel more secure, but potential clients might use this as a requisite when deciding to conduct business with a company.

I am disappointed to see the strength indicator removed and I will likely re-add it / use a patched version of the plugin.

Cheers,
Dean.

Hi Dean:

Thanks for your persistence. Those systems provide strength indicators in their user interfaces because they don’t actually enforce password strength, so they need some way to nudge users to do the right thing. But the Login Security Solution plugin _requires_ the users to get it right.

While it’d be nice for LSS to provide a UI clue while people are typing, the LSS’ rules are so complex that it’d be unwieldy. LSS permits the use of UTF-8. The upper case / lower case check (with exceptions for alphabets that only have one case) is hard enough to do in PHP, let alone JavaScript. Plus we require that the password doesn’t contain user name, site name, etc. All of this would require a lengthy, complex back and forth via AJAX.

The specific character and length requirements are specified in text below the password fields. (Guess I need to add text mentioning that one’s name and site info can’t be in the password.)

I’d welcome a patch that covers all of this in a clean, effective way. It’d have to account for the fact that with LSS, it’s either a strong password or it’s not; there’s no weak/medium/strong gradation. I guess it’d have to be a check list kind of thing.

Thanks,

–Dan

Hi Dan:

I do not believe any password should progress via any AJAX back and forth as you mention – insecure, less exposure of the password to the network the better – perhaps an exception is where HTTPS is ensured.

The key points are:

• The password strength indicator doesn’t need to cover every edge case.
• Covering the post common cases of bad passwords is good and beneficial to the user experience.
• If the meter does not give a complete indication that the password will be successful, perhaps include a message to that effect.
• With regards to upper case and lower case, they are locale specific so you will never get this check right on the server side. The best you can do is Unicode default mapping of characters, so this might not meet users expectations. For default mapping see example JavaScript below.

With regards to the JavaScript case check, JavaScript has Unicode support as such the case check can be expressed as:
function hasUpperAndLower (str) { return str.toUpperCase() !== str.toLowerCase (); }

Remember the KISS principle, the complexity is in the server side you have already done all the hard work there. When they hit submit it’s gonna get validated. Don’t prevent the user from submitting, cover the most common mistakes in the indicator.

Perhaps get in touch with some of the UI people and check to see if the password strength meter as any UI refresh plans:
https://make.www.ads-software.com/ui/
This is something I was going to mention before, WordPress UI/UX changes are passed by the community and User Experience professionals / review them before they get anywhere near the core.

Stay focused on the user experience if it’s JavaScript / UI messaging, this is the one area every user most use.

Cheers,
Dean.