• Version 7.0 has two ‘convenient’ default settings: (1) “password age” of 120 days – forcing basically all users to change their password, and (2) “strong passwords” – also typically causing all users to change their password. iThemes has elected to enforce these changes by default and override your current settings as the website owner/administrator. Is anyone aware of a method for keeping your default settings in place when performing a plugin update so that you and your many users are not forced to change their passwords?

Viewing 11 replies - 1 through 11 (of 11 total)
  • If I’m not mistaken the plugin should allow you to change the settings any way you want (after the plugin update).

    But I agree it’s better to prevent this from happening than having to fix your settings afterwards.

    It’s certainly something to be aware of 😉

    Thread Starter coltwest

    (@coltwest)

    Yes, you can change those settings after the update. The issue here for me is that I have 147 websites using the pro version of the plugin and those sites have over 10,000+ users combined. Of course, many people have not changed their password in over 120 days and many do not have “strong passwords” as defined by WP. Security is important no doubt, but to have the new version of the plugin default to these settings being enforced when the current plugin settings have those settings disabled is over reaching the configuration the website owner/administrator has established.

    Most of my customers (the website owners) elected to not have these settings enabled to begin with by choice. iThemes has taken away that choice with this update. Hopefully, iThemes will issue an update to not have these settings enabled by default and to respect the settings of the current plugin installation.

    My workaround was to revert back to the prior iThemes Security Pro release en mass (via MainWP) and everything is good again. Thankfully, I had a copy of the prior release to use. I’ll just have to wait it out and see if iThemes comes to their senses and issues a quick fix.

    • This reply was modified 4 years, 10 months ago by coltwest.

    @coltwest,

    We’re with ya!

    We’re experiencing (and have reported to iThemes) numerous issues with iTSec Pro V7.0.0.

    Let’s hope the iThemes’ DevOps team will heed our findings and recommendations (9 so far) and do something about them.

    Unfortunately, iThemes has no active forum (e.g., within its own website, stack exchange, or GitHub) for peer-to-peer assistance, so we’re left with sharing our findings or tidbits via this one.

    Yes, we also plan to downgrade to V6.8.5 if V7.0.0 is not fixed very soon.

    Side Note: We’re following SG Security (released June 7, 2021) which has amassed 20,000+ customers in only 17 days. If V7.0.0 is not fixed very soon, rather than downgrading to V6.8.5, we may start using SG Security. Not promoting this plugin, just sharing what we just learned.

    Cheers!

    @timothyblynjacobs

    Are the old constants like ITSEC_DISABLE_PASSWORD_REQUIREMENTS still functional in the new plugin release ? And if so can these be used as a solution for the issue raised in this topic ?

    • This reply was modified 4 years, 10 months ago by nlpro.
    • This reply was modified 4 years, 10 months ago by nlpro.
    • This reply was modified 4 years, 10 months ago by nlpro.
    Plugin Contributor Timothy Jacobs

    (@timothyblynjacobs)

    Yep, all those existing constants are still supported. We also pushed out 7.0.1 yesterday which fixes the underlying issue.

    As of 7.0 Password Requirements are enabled if any user group has the requirement enabled for them. That is, there’s no longer a separate Password Requirements module page where you need to enable the requirement itself to see the option to use there requirement in the User Groups page. However, on upgrade, user groups weren’t cleared for Password Requirements that were disabled. So if a requirement was disabled, but had User Groups attached to it, when you upgraded to 7.0 it was enabled again.

    7.0.1 fixes this issue and runs an upgrade routine, so those Password Requirements should automatically be disabled again without you having to make a configuration change to all of your websites.

    @timothyblynjacobs

    Nice !

    Perhaps usefull to mention that Pro 7.0.1 fixes this issue AND 6 other bugs 😉
    For a list of those 6 other bug fixes check out the Pro 7.0.1 ChangeLog.

    @coltwest
    I guess this topic can be marked as resolved (in Pro 7.0.1).

    @nlpro,

    Unfortunately, iThemes Security Pro’s Changelog URL is a huge mystery.

    Most plugins (free and pro) have a PUBLIC URL for their changelog.

    Here’s a good example: https://wp-rocket.me/changelog/

    The one provided by iThemes is:

    https://members.ithemes.com/packages/ithemes-security-pro/changelog.txt

    Above cannot be accessed unless you’re a member and/or logged in. Why? Preposterous.

    @timothyblynjacobs,

    Please make the iThemes Security Pro Changelog PUBLIC. Thank you!

    Cheers!

    @jetxpert

    I don’t see what the problem is. By default EVERY WordPress site where the iTSec Pro plugin is installed provides a publicly accessible changelog. Like the one on iThemes site 😉

    Is that iThemes using their own security plugin on their site ? I’m shocked! Since when did that happen? Oh by the way, it has not been updated to the 7.0.1 release (yet)…

    iThemes, please update your own copy of the iTSec Pro plugin. Just keeping it up to date will provide the community with a publicly accessible (and up to date) Pro changelog 😉

    • This reply was modified 4 years, 10 months ago by nlpro.

    @nlpro,

    Thanks for the link you provided. New to us.

    Now … please correct us if we’re wrong … you provided a direct link, which is not available on their website (menu). Further, not everyone knows where or how to find the direct link you provided.

    To confirm the link you provided is not exactly “public”, if you remove the last parameter(s) from your link, you’ll get a blank page rather than a reference to the iThemes website page for iThemes Security Pro.

    Based on iThemes’ current website design, the “Changelog” URL you provided for iThemes Security Pro should be made public and placed here.

    Cheers!

    All I’m saying is that the Pro changelog is public to me (and basically everyone).

    It can (almost) always be accessed using the very same URL. Ok, the file is named history.txt (instead of changelog.txt) but who cares. It’s also no URL parameter. We are just accessing the plugin history.txt file directly through the web server from a browser. This isn’t exactly rocket science… (The only times this won’t work is when the web server is configured to not allow .txt files to be accessed directly from a browser or when the file is simply deleted from the plugin root folder for eg security reasons).

    Also if you remove the history.txt part from the url, the web server will default to serving the index.php file (which also exists in the plugin root folder). And that file is full of endless emptyness …:

    <!-- You don't belong here. -->

    Result: an utterly empty page.

    I understand you just want an up to date changelog link to click on outside their members panel. However there doesn’t seem to be one. So let’s simply make use of a workaround.

    Go to the link I provided in my previous post and then add it as a favorite to your browser. Done!

    Oh, I just checked, it seems like iThemes updated the plugin on their site. So the link provided in my previous post now includes the Pro 7.0.1 changelog entries 😉

    @nlpro,

    Do you work for iThemes?

    Do you think we’re dumb? (Re: Bookmarking the link)

    We’re trying to help the community. Such an easy thing to do (adding the Changelog URL to iThemes’ website menu like most other plugin sites do).

    Peace. We’ve migrated to another Security plugin.

    Cheers!

Viewing 11 replies - 1 through 11 (of 11 total)

The topic ‘New Forced “Default” Settings’ is closed to new replies.