zxcvbn bootstrap password strength meter and secure headers mods

[Jeff]

I have made a few modifications to the 4.3.4 version:

1. make use of a modified version of the zxcvbn bootstrap password strength meter as shown on

http://martinw.net/zxcvbn-bootstrap-strength-meter/

2. add secure headers which improve the grading of a fresh install of 4.3.4 from grade D to grade A when scanned on

https://securityheaders.io/

If you are interested what would be the best way to submit these changes?

[Brandin]

I would love to add the password strength as an input addon. If it's not too many code changes just upload it to hastebin or something. Same with the secure headers! Thank you!

[Jeff]

Password Strength Meter modification


1. Copy and paste the code in the JS pane from https://codepen.io/Scally/pen/mqXXZz

Save with filename: zxcvbn-bootstrap-strength-meter.js

and put the js file in: users/js folder


The original js file can be found at https://github.com/martinwnet/zxcvbn-boo...ngth-meter

I have added this modification to disable the 'submit' button until a password has a Strong or Very strong value.


// modification to disable submit button on _join.php and _forgot_password_reset.php until password strength is Strong or Very Strong
if ( result.score < 3 ) {
$('#password_strength').prop('disabled', true);
} else {
$('#password_strength').prop('disabled', false);
}


One problem I have not been able to solve - the submit button only becomes disabled after an entry has been made in the password field, but the existing validation will not allow blank passwords.




2. Copy and paste the code in the HTML pane from https://codepen.io/Scally/pen/OOQQKq

Save with filename page_footer.php

and the put the php file in: users/includes

This is a modified version of page_footer.php from Userspice version 4.3.4

One problem - I have not been able to find an integrity value for the 'zxcvbn' password strength library file.






3. The remaining files are modified versions of files from Userspice version 4.3.4

Copy and paste the code in the HTML panes from each of these CodePens and save as php files:


modified version of _join.php - https://codepen.io/Scally/pen/JOpLoO
location: users/views folder




modified version of _forgot_password_reset.php - https://codepen.io/Scally/pen/qVxoOx
location: users/views folder




modified version of user_settings.php - https://codepen.io/Scally/pen/JOpLdM
location: users folder


I have found a problem with the original user_settings.php file:

When you update your user settings, and success messages are displayed on selecting Update, the updated values are saved but the screen does not show the updated values.

[Jeff]

Secure Headers modification for 4.3.4

Copy and paste the code in the HTML pane from https://codepen.io/Scally/pen/wPyjgd

modified version of header.php
location: users/includes folder

Seven security headers are identified in this modification, only the content-security-policy HTTP header has not been applied.
My understanding is that the content-security-policy header provides a whitelist of approved external and internal sources of files used by the site.
It would be possible to identify those sources used by UserSpice, but you are not able to identify sources needed in user pages.

With each header I have given optional settings that might be used to tweak performance.

I hope the settings I have started with and the location of the mod in the header.php file are OK.
I have used https://securityheaders.io/ to scan the site before and after applying this modification.

[mudmin]

Awesome! Thanks so much for this! I've added it to my todo list!

[mudmin]

First of all, thank you for the fantastic work! I was able to include the header improvements. I put them in usersc/includes so that people can edit them as needed.

Regarding the password strength, there are a few things we'll need to do to get it fully backed.

I think the strength required should be a variable set in the db (it appears to be 0-5). That shouldn't be too hard but it will take some time.

I also think the includes should only be included on files that need them. I'd rather not include a bunch of stuff in the header or footer, so I put a users/includes/password_meter.php to store all this code at once.

The other issue we have is that if we're relying on JS to prevent weak passwords, users could be running noscript or something similar and that would cause issues.

Finally, whatever we do, should be across the board. Otherwise a user will have a strong pw at signup and then just change it in user_settings where we can't block the update button because people might not be updating their pw.

Still have to work through some details. Thanks for everything!

[Jeff]

With hindsight, it is not necessary to block/disable the submit/button on password related forms with weak passwords, providing the user clearly knows the password they have chosen is 'weak' or 'strong'. It is more a case of giving sound password advice.

The standard Userspice version is already dependent on JS routines which would also fail for any user running noscript. There would be no problem with the password strength script - if this script fails to work, users are free to use passwords of any strength.

[Jeff]

Other headers might be used to disable caching of potentially sensitive data:

header("Cache-Control: no-store, no-cache, must-revalidate", true);
header("Expires: Sat, 1 Jan 2000 00:00:00 GMT", true);
header("Pragma: no-cache", true);

[mudmin]

Right on the password meter. The only thing we're absolutely enforcing at this time is length. I agree. I'm going to put it in as a visual understanding of the strength of the password. Definitely. Again, thanks for your work and thanks for the additional headers.

Are you suggesting that those headers above be put on certain pages or used site wide?

[Jeff]

I am not an expert on site security - it would appear that as soon as one security hole is plugged another will appear. Hackers can be extremely resourceful and the best one can do is make life as difficult as possible for the hacker without making your application unusable.

As with password choices, security headers could be offered as an option for users to make. A basic set of secure headers could be recommended for all users with others as an option. Much would depend upon what type of application each user is developing.

http://searchsecurity.techtarget.com/ans...a-security offers some advice on cache control.

Perhaps a suck and see approach is the best option when you do not know how Userspice is going to be used by a user. Offer a list of headers for selection/deselection on the understanding that if selected and everything still works then one more potential security hole has been blocked.