The problem

I regularly have a debate with my CTO which usually begins something like this ...

CTO: My password expired, that should never happen. 
Me : It's a security risk to never expire passwords. 
CTO: It's a security risk to force passwords to be reset because users have bad habits. 
Me : Yes but the security is in the user not the system, enforcing password expiry ensures the system is secure in the event of an unknown breach of the userbase.

This raises an interesting question that neither of us primarily not being a system administrator but being a position that we need to apply a policy to this effect don't really agree on what the right answer should be.

My standing

The system is more secure if you force all users to change their passwords in X amount of time where X is computed by determining the algorithm strength used to protect the password and an estimated time to break (with brute force) the raw value back in to the original password.

CTO's Standing

The act of forcing users to change their passwords all the time results in patterns / ****123 "like" patterns over time or users write passwords down meaning the users "bad habit" is more of a risk to the system than the data being compromised in some more technical manner (e.g. through brute forcing).

So I would like to know

Is there some way I can prove either way weather or not we should enforce a password reset policy based on some industry best practice?

OR

Is one of us just plain wrong?

  • It's Linux or Windows environment? – Alexander Tolkachev Dec 14 '17 at 12:35
  • It applies to both I would say ... it's more general to managing passwords. Do you see password management as needing different treatment depending on the domain type / server environment? I figured the key was the practices not the specifics (e.g. exactly how the password is stored isn't relevant it's a question of how best to look after it) in this case. – War Dec 14 '17 at 12:37
  • 2
    I note that the latest version of the NIST guidelines on the subject recommend NOT expiring passwords without a good reason. nakedsecurity.sophos.com/2016/08/18/… – Michael Kohne Dec 14 '17 at 12:53
  • A great read ... some really interesting stuff in there thanks @Michael – War Dec 14 '17 at 13:41

Your CTO is more right, but it's a more complex issue. NIST ( https://csrc.nist.gov/ ) is probably the "industry best practices" reference.

When it comes to passwords length, not complexity or frequent changes, is the way to go. ( https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/ ) They suggest phrashes or sentences rather than a single word.

You describe hashing passwords before storing them which is the logically better alternative than plain text. The problem is with multi-gpu systems tens to hundreds of hashes can be calculated and checked per second.

The links below discuss the changes. I'd suggest paying special attention to salting passwords before they're hashed.

https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/

https://www.passwordping.com/surprising-new-password-guidelines-nist/

https://softwareengineering.stackexchange.com/questions/216998/updating-password-hashing-without-forcing-a-new-password-for-existing-users

Yes, it increases security risks if you don't force passwords to expire.

As your CTO said, because we have bad habits, passwords will eventually leak one way or another, e.g. type the password in the user input field, leave it unencrypted in some application config file, etc.

Forcing users to change passwords reinforces security in terms of availability, a leaked password that expires in 15 days will force the attacker to take advantage of it in the next 2 weeks, whereas a permanent password will leave a door open to external danger.

If you see this from the attacker's point of view as well, it's pretty deterring to know you may be able to sniff a password after several weeks stealing data only to see that halfway that process all those passwords changed and you have to start over.

Sometimes the best way to make your system harder to crack isn't to make it more robust, but rather to avoid harm altogether by letting people know they'll waste their time.

To me it looks like you have a lazy CTO who doesn't want to come up with new passwords.

  • I think your threat model is way off base. Hostiles don't get passwords by slowly sniffing, you get them by by phishing. And then you immediately use them to get what you want, or you implant malware that makes the password irrelevant to you. – Michael Kohne Dec 14 '17 at 13:00
  • @MichaelKohne You are talking about a different case scenario. Password expiry policies have nothing to do with directly stealing a password and using it, which is out of the question context. – Héctor Álvarez Dec 14 '17 at 13:43
  • To sum it up, passwords expiry policies limit the time frame when identity theft works, attack vectors are blocked through other means if the need arises. – Héctor Álvarez Dec 14 '17 at 15:26
  • Except that in most modern cases the hostile doesn't NEED to maintain the credentials. They either do their dirty work immediately, or they implant something so they can get back in even if you change the password. With the exception of very high value target (who should be using MFA anyway), it's pointless. – Michael Kohne Dec 14 '17 at 15:47
  • @MichaelKohne I still don't know where you get your logic, password expiry policies are there for the same reason you have a key lock at home. You don't want to get robbed by every single person you come across, but you definitely won't stop James Bond from stealing your data. You seem to assume the only attack vector is directly stealing someone's credentials, while this protects you passively over time. Long story short, enforce regular password expiry policies. – Héctor Álvarez Dec 20 '17 at 17:10

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.