The logic behind so-called "best practices". Question one: password expiration
-
@Carnival-Boy said:
Again, 365 seems an arbitrary number to me.
It's somewhat arbitrary but it is based around humans, which will always seem kind of arbitrary. It is about being as short as possible without causing people to be unable to handle it.
-
@Carnival-Boy said:
No-one is going to spend a year attempting to crack a password for a typical SMB. They'll either crack it in a day, or a few hours, or give up.
Agreed. Not applicable if looking for an industry-wide best practice. But applicable if we are only looking at low value target SMBs. The average firm has very little worth stealing, the cost to steal only has to be higher than the value of what can be stolen.
-
@Carnival-Boy said:
All the security attack demos I've seen have involved getting into the network via a non admin account and then quickly getting access to an admin account, and/or installing malicious software. The non admin account has always been the way into the network but it's never been used once inside. It's like a burglar climbing through the window, but after that using the front door to take stuff out.
Depends if your goal is to protect against a professional (or nearly so) external attacker or if you are trying to protect against the bulk of attacks, which are internal ones.
The biggest password threat is it being written down or shared. Lots of people do this. If someone was to casually get someone else's password through normal transactions and later, maybe a year or two, became disgruntled, it is nice to know that the chances that the passwords that were incorrectly shared with them no longer work.
-
@scottalanmiller said:
Two is that changing sometimes means that other mistakes, like accidentally unlocked accounts, can't be compromised for forever.
This is a great point. It's basically doing one practice in order to mitigate against bad practices elsewhere (like keeping on top of expired accounts).
This brings me to the main reason I expire passwords. I work in a culture of password sharing amongst users. Instead of addressing this culture (through a mix of user education and management enforcement), I use password expiration to mitigate the effects of the culture. This takes two forms:
- Constantly changing passwords makes it inconvenient for users to share passwords. If you make something inconvenient, they are less likely to do it.
- People will forget to tell people their new user passwords, so the shared password has expired.
Many times I've had a user phone me up and say this:
Sue: "I'm trying to log on to Bob's PC but it says the password is invalid".
Me: "Well, maybe you have the wrong password"
Sue: "Well, I wrote it down and I've used it before"
Me: "Well then, you probably have his old password but not his new password"
Sue: "Oh, ok. Can you tell me what his new password is then?"
Me: "No. I don't know what it is either."
Sue: "So I can't log in using Bob's credentials any more"
Me: "No!" -
@scottalanmiller said:
If someone was to casually get someone else's password through normal transactions and later, maybe a year or two, became disgruntled, it is nice to know that the chances that the passwords that were incorrectly shared with them no longer work.
Yeah, that was AJ's point. But if that is an issue, the risk of it happening reduces the shorter your expiration time. So 90 days becomes better than 365 days, for example.
I appreciate it's finding a balance between all the different kinds of risks and trying to come up with a magic number.
-
@Carnival-Boy said:
Yeah, that was AJ's point. But if that is an issue, the risk of it happening reduces the shorter your expiration time. So 90 days becomes better than 365 days, for example.
But 90 days is widely seen as infuriating to users and way below the "I don't care and am just writing it down now" threshold for a lot of people.
-
@scottalanmiller said:
@Carnival-Boy said:
Yeah, that was AJ's point. But if that is an issue, the risk of it happening reduces the shorter your expiration time. So 90 days becomes better than 365 days, for example.
But 90 days is widely seen as infuriating to users and way below the "I don't care and am just writing it down now" threshold for a lot of people.
We change every 90 days. Users love to spout out their passwords to me. One pattern i see on our users is they make their passwords like this Password1!, Password2!, Password3!
No problem because that can be changed right? Then they do this.... FirstChild'sName!, SecondChild'sName!, Dog'sName!
In reality those are just as weak as Password1!, Password2!, etc -
@IRJ said:
@scottalanmiller said:
@Carnival-Boy said:
Yeah, that was AJ's point. But if that is an issue, the risk of it happening reduces the shorter your expiration time. So 90 days becomes better than 365 days, for example.
But 90 days is widely seen as infuriating to users and way below the "I don't care and am just writing it down now" threshold for a lot of people.
We change every 90 days. Users love to spout out their passwords to me. One pattern i see on our users is they make their passwords like this Password1!, Password2!, Password3!
No problem because that can be changed right? Then they do this.... FirstChild'sName!, SecondChild'sName!, Dog'sName!
In reality those are just as weak as Password1!, Password2!, etcThere is a simple solution... stop making them change it that often. Do that to me and I stop caring about the "security" of the company too and will resort to the same thing.
-
tl;dr all the others.
Our password policy is change every 42 days with complexity and length requirements... Because audit requirements.
Lolwut? I hear you ask, well working is a subsidiary of a government department means we are still a part of it and are entitled to have these forced upon us.
-
I think that with end users being end users, forced change is a good thing but it has to be more than 30 days for reasons already mentioned by @scottalanmiller .
I think 90 days is probably the winner as... Well... It just smells better.
60 days seems a bit odd
42 is just strange (I don't make the policies)
And 30 is just too short. -
@nadnerB said:
I think 90 days is probably the winner as... Well... It just smells better.
I put this in the same category as "change every day." It's so often that users are pissed and don't take you seriously anymore. IT becomes an adversary. Honestly, if you do this to me, that's how I feel. Make it anything less than a year and I don't feel like security is my responsibility. I make my passwords random and hard and I can't remember new ones every three months. Can't and won't. I can be secure or I can make you happy with constant changes. It's your choice. If you do anything close to 90 days I'm going to stick a number in there and increment it. Every time. If security has that little importance, I'm sure not going to go out of my way making it hard for me for something given so little thought by the company.
To me, one year is an absolute minimum. And even that is pushing it a bit. But one year I can handle. Most people, I think, cannot. Two years is really far better. Six months or less, though, and you are well into very annoying and problematic territory for average people.
-
@scottalanmiller well, no one said it's a one size fits all :p. To keep within our requirements, that's how we have to play it.
Yes, a lot of our end users are incrementers as a result. I choose not to be.
I prefer a very strong and long-life password over a frequently changed weak password.
-
@nadnerB said:
@scottalanmiller well, no one said it's a one size fits all :p. To keep within our requirements, that's how we have to play it.
I understand, you are doing it because some civil servant decided that making a forced insecure requirement would look better on getting a promotion than actually protecting the government. Same way it works here. It's just a form of corruption - in this case, probably some combination of inept, lazy or just willing to be insecure to avoid the same issues from inept or lazy people above them. Somewhere, someone who doesn't understand security (we hope that's all that it is) makes the decisions as an administrator and not as an IT pro. It's corrupt because obviously they know that they don't know anything about security, yet they make the judgement call anyway. Hopefully their corruption is just in being inept and being willing to do a job they don't know how to do.
-
@scottalanmiller said:
@nadnerB said:
@scottalanmiller well, no one said it's a one size fits all :p. To keep within our requirements, that's how we have to play it.
I understand, you are doing it because some civil servant decided that making a forced insecure requirement would look better on getting a promotion than actually protecting the government. Same way it works here. It's just a form of corruption - in this case, probably some combination of inept, lazy or just willing to be insecure to avoid the same issues from inept or lazy people above them. Somewhere, someone who doesn't understand security (we hope that's all that it is) makes the decisions as an administrator and not as an IT pro. It's corrupt because obviously they know that they don't know anything about security, yet they make the judgement call anyway. Hopefully their corruption is just in being inept and being willing to do a job they don't know how to do.
That's a lot of pent up frustration, bad experience or just frustration at ignorant buttheads making rules they don't understand?
Anyway... Yeah, sounds about right.
