The other reason you want to enforce strong passwords for your users

In a conversation I was having recently with a cryptography enthusiast I was reminded of a very important reason you may want to enforce strong/complex passwords on your website.

As a website administrator most of us are concerned with our first line of defense: Preventing hackers from gaining access to our website. So we focus on hiding the administrator user, limiting login attempts and of course enforcing hard to guess passwords. However it’s easy to fall into the trap of only thinking about an external hacker brute forcing their way into your website. It’s easy to think “Well my passwords is fairly hard to guess and they only have 20 guesses (or 10 or 5 depending on your Wordfence settings) before they get locked out anyway.

The problem is that if a hacker does gain access to your site, the first thing they’re going to go for is the encrypted password file – or in the case of WordPress, the table in the database that contains the encrypted passwords, which is wp_users, unless you’ve changed your table prefix.

Then they will find a very fast machine, or a cluster of very fast machines, and run a brute force app on the local password data that has unlimited tries at guessing each password in the file and is not slowed down by bandwidth or latency limits. It’s quite feasible for someone to work at brute forcing your downloaded password table at a rate of several billion guesses per second using a single machine with a GPU. See a few John-the-Ripper benchmarks here.

“Why do I care, my site has already been compromised?” you might say. The issue is that many users have the bad habit of using the same password across multiple websites and that’s why the hacker grabbed your password file and is throwing significant resources at brute-forcing it: So that they can gain access to the real treasure-trove of Gmail accounts, LinkedIn, Facebook, Hotmail, Quicken, Paypal, eBay and all the other valuable accounts out there that let them steal real money from real people who are members of your website.

This is why, even if you have brute force protection on your site, you should enforce strong passwords: To protect your customers other accounts on the Web in the worst-case-scenario of your site being compromised and your wp_users table being downloaded.

As a WordPress publisher, to enable strong-password-enforcement through Wordfence, simply go to your Wordfence ‘options’ page, scroll down to “Login Security Options” and check the box to “Enforce strong passwords”. Then scroll up to the “Scans to include” section and check the box for “Check the strength of passwords”. Then hit save and you’re done. This is another great free feature of Wordfence.

Being the owner of a community website comes with a few responsibilities and protecting your users in a worst-case-scenario is one of them. I encourage you to spread this message to your members, users and customers and let them know the risks of using the same password across multiple websites and the benefits of using passwords that are unique and hard to guess.

Happy publishing!!!

Thanks to Ricky Pattillo for his contribution to this blog entry.



Did you enjoy this post? Share it!


1 Comment
  • I just wanted to say that your plugin has been a lifesaver and I appreciate all the tips to secure my blog. Thank you!

    I wanted to comment on something that affects security of blogs, and that is the "admin" login. While one can be sure to change that common mistake, there still remains the problem of the user login being accessible by anyone. All one has to do is hover over the author of a post and they will be able to see the user login on the bottom address bar.

    This seems to be an on-going problem within WordPress, and I am concerned that new bloggers will not realize or know how to change it as it DOES take a bit of doing. (Even though I managed to change it, I am still uneasy about it.) Thankfully, Wordfence provides some ways to counteract that problem.

    I feel this problem could have an added layer of protection by either the creation of a plugin that would address this problem, or that the creators of the themes could encode something that would change this practice within the theme itself.

    I'm probably not expressing myself clearly as the technical terms are beyond my understanding. I just hope that someone can understand this and address this problem.

    Again, thank you for such a wonderful plugin..It really has been a site-saver for me!