What is the best way to update passwords on my terms with users?
Question asked by Nathan McKay - 12/28/2018 at 12:39 PM
So, Might have been already mentioned--But I want to make sure guidelines are relevant to our version (15).
I want to push out password changes on my terms. I want to update length, chars needed (Special, upper), and disable common phrases (Like Password). Probably going to add in months and seasons. 

I don't want any accounts to auto-shut off--I want to shut them off by hand. I say this cause the company has grown over the years with several IT personnel who mostly are no longer with us, and It will take time to find every script that uses an email address. What is the safest way to accomplish this (IE. Update password requirements)?

Also, can anyone provide some "DO NOT DO....." advice as well, on this front? Would like to avoid the mistakes yall have seen and heard about.

1 Reply

Reply to Thread
Scarab Replied

You can grandfather existing passwords from meeting new password requirements by not enabling the EXPIRE PASSWORDS setting and enabling the DISABLE PASSWORD STRENGTH FOR EXISTING PASSWORDS. This allows everything that is currently configured to continue "as is" while enforcing all your other Password Requirements for new accounts and any future password changes.

This is precisely what we have done for the past couple of years as it doesn't interfere with anyone's existing SMTP Authentication cofigured on their websites or server scripts, printers and security cams that they have set long ago and forgotten about, etc. Although we have repeatedly sent emails to every user with simple passwords every year, strongly suggesting that they change their passwords to a strong password, we do not enforce it by requiring them to do so (and have subsequently found that 99% of users won't bother to update their password on their own time). Instead, when an account with a simple password gets compromised the account gets locked down and a complex password is generated and set for that account manually. At that point, if the customer wants to recover their account and change their password to one of their own choosing then they must meet the new minimum Password Requirements, NO EXCEPTIONS. Even the most resistant of elderly users is pretty understanding under those circumstances.

As we have long been awaiting 2FA in v17/v100, we are planning on becoming more heavy-handed with Password Requirements this year. If a user wants to use a simple password that does not meet the minimum Password Requirements then they *MUST* enable 2FA by year end, otherwise they must change their password to a strong password that meets the minimum Password Requirements we have set in SmarterMail. I am suspecting that it still won't be pretty from a Technical Support standpoint, but it has to be done.

Reply to Thread