Sometimes I think that title is the job of the Security Engineer â€“ as a Subject Matter Expert, weâ€™re supposed to meet with teams and tell them how their dreams are going to come crashing down around their ears because of something they hadnâ€™t thought of, but which is obvious to us.
This can make us just a little bit unpopular.
But being argumentative and sceptical isnâ€™t entirely a bad trait to have.
Sometimes it comes in handy when other security guys spread their various statements of doom and gloom â€“ or joy and excitement.
â€śRename your administrator account so itâ€™s more secureâ€ť â€“ or lengthen the password and achieve the exact same effect without breaking scripts or requiring extra documentation so people know what the administrator is called this week.
â€śEncrypt your data at rest by using automatic database encryptionâ€ť â€“ which means any app that authenticates to the database can read that data back out, voiding the protection that was the point of encrypting at rest. If fields need encrypting, maybe they need field-level access control, too.
â€śComplex passwords, one lower case, one upper case, one number, one symbol, no repeated lettersâ€ť â€“ or else, measure strength in more interesting ways, and display to users how strong their password is, so that a longish phrase, used by a competent typist, becomes an acceptable password.
Now Iâ€™m going to commit absolute heresy, as Iâ€™m going against the biggest recent shock news in security advice.
I understand the arguments, and I know Iâ€™m frequently irritated with the unnecessary requirements to change my password after sixty days, and even more so, I know that the reasons behind password expiration settings are entirely arbitrary.
Thereâ€™s a good side to password expiry.
These arenâ€™t the only ways in which passwords are discovered.
The method that frequently gets overlooked is when they are deliberately shared.
â€śBobâ€™s out this week, because his mother died, and he has to arrange details in another state. He didnâ€™t have time to set up access control changes before he left, but he gave me a sticky-note with his password on it, so that we donâ€™t need to bother him for anythingâ€ť
â€śEveryone on this team has to monitor and interact with so many shared service accounts, we just print off a list of all the service account passwords. You can photocopy my laminated card with the list, if you like.â€ť
Yes, those are real situations Iâ€™ve dealt with, and they have some pretty obvious replacement solutions:
Bob (or Bobâ€™s manager, if Bob is too distraught to talk to anyone, which isnâ€™t at all surprising) should notify a system administrator who can then respond to requests to open up ACLs as needed, rather than someone using Bobâ€™s password. But he didnâ€™t.
When Bob comes back, is he going to change his password?
No, because he trusts his assistant, Dave, with his communications.
But, of course, Dave handed out his password to the sales VP, because it was easier for him than fetching up the document she wanted. And sales VPs just canâ€™t be trusted. Now the entire sales team knows Bobâ€™s password. And then one of them gets fired, or hired on at a new competitor. The temptation to log on to Bobâ€™s account â€“ just once â€“ is immense, because that list of customers is just so enticing. And really, who would ever know? And if they did know, everyone has Bobâ€™s password, so itâ€™s not like they could prosecute you, because they couldnâ€™t prove it was you.
Whatâ€™s going to save Bob is if he is required to change his password when he returns.
Yes, this also happened. Because we found the photocopy of the laminated sheet folded up on the floor of a hallway outside the lavatory door.
There was some disciplining involved. Up to, and possibly including, the termination of employment, as policy allows.
Then the bad stuff happened.
The team who shared all these passwords pointed out that, as well as these being admin-level accounts, they had other special privileges, including the avoidance of any requirement to change passwords.
These passwords hadnâ€™t changed in six years.
And the team had no idea what would break if they changed the passwords.
Maybe one of those passwords is hard-coded into a script somewhere, and vital business processes would grind to a halt if the password was changed.
When I left six months later, they were still (successfully) arguing that it would be too dangerous to try changing the passwords.
Iâ€™m not familiar with any company that acknowledges in policy that users share passwords, nor the expected behaviour when they do [log when you shared it, and who you shared it with, then change it as soon as possible after it no longer needs to be shared].
Once you accept that passwords are shared for valid reasons, even if you donâ€™t enumerate what those reasons are, you can come up with processes and tools to make that sharing more secure.
If there was a process for Bob to share with Dave what his password is, maybe outlining the creation of a temporary password, reading Dave in on when Dave can share the password (probably never), and how Dave is expected to behave, and becomes co-responsible for any bad things done in Bobâ€™s account, suddenly thereâ€™s a better chance Daveâ€™s not going to share. â€śI canâ€™t give you Bobâ€™s password, but I can get you that document youâ€™re afterâ€ť
If there was a tool in which the team managing shared service accounts could find and unlock access to passwords, that tool could also be configured to distribute changed passwords to the affected systems after work had been performed.
If you donâ€™t have these processes or tools, the only protection you have against password sharing (apart from the obviously failing advice to â€śjust donâ€™t do itâ€ť) is regular password expiry.
Iâ€™m also fond of talking about password expiration as being a means to train your users.
Certificates expire once a year, and as a result, programmers write code as if itâ€™s never going to happen. After all, thereâ€™s plenty of time between now and next year to write the â€śrenew certificateâ€ť logic, and by the time itâ€™s needed, Iâ€™ll be working on another project anyway.
If passwords donâ€™t expire â€“ or donâ€™t expire often enough â€“ users will not have changed their password anything like recently enough to remember how to do so if they have to in an emergency.
So, when a keylogger has been discovered to be caching all the logons in the conference room, or the password hashes have been posted on Pastebin, most of your users â€“ even the ones approving the company-wide email request for action â€“ will fight against a password change request, because they just donâ€™t know how to do it, or what might break when they do.
Unless theyâ€™ve been through it before, and it were no great thing. In which case, theyâ€™ll briefly sigh, and then change their password.
This is where I equivocate and say, yes, I broadly think the advice to reduce or remove password expiration is appropriate. My arguments above are mainly about things weâ€™ve forgotten to remember that are reasons why we might have included password expiry to begin with.
Here, in closing, are some ways in which password expiry is bad, just to balance things out:
Right now, this is where we stand:
As a result, especially of this last item, I donâ€™t think businesses can currently afford to remove password expiry from their accounts.
But any fool can see which way the wind is blowing â€“ at some point, you will be able to excuse your company from password expiry, but just in case your compliance standard requires it, you should have a very clear and strong story about how you have addressed the risks that were previously resolved by expiring passwords as frequently as once a quarter.