|
It's their server, so they're right, so you have to deal with it. It is, however, your right to complain bitterly to whomever will listen.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Exactly. I've been a contractor (Consultant) for most of my 45 year it IT. Early on I learned two things;
1. Behave like a mercenary, if they want you to kill it, as long as its not illegal, unethical or immoral, kill it.
2. They can pay me now or they'll pay me later, either way I get paid.
Every one of my clients were happy with me.
|
|
|
|
|
|
Such passwords will be written down. If someone changes the lock on their front-door each month, I'd be inclined to say that they haven't looked into securing the house at all and are merely copying others.
I'd also be testing their password recovery/reset options at least twice a month 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
It depends. If they're in an industry that has applicable cyber regulation then they may absolutely need to do this to maintain compliance.
Thirty days seems a little on the sharp side, but that's all contingent on the laws in the primary operational area for the company.
Also, the general "wisdom" on the security side is that complex passwords that are changed on a regular basis are still a fundamental security practice. The zeitgeist has not shifted on that; though there are a number of increasingly vocal individuals that advocate for a less complex strategy, they don't represent the viewpoint of the community as a whole.
Use KeePass to keep it easy. I just use the "Generate from last" and go.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Yes, if they are too lazy to restrict access for ex-employees, then it would pay to change those passwords every 30 days. Would give said employee to the end of the month to create chaos.
It is nonsense.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
No, if the organization is subject to regulation then out-processing requirements are likely required as well, which should include account closure. Of course, if there are a ton of different systems without a central AAA mechanism then it might be as you suggest, but only a complete moron would consider that a security strategy.
This isn't an insider threat mitigation strategy. As I said, 30 days is a bit much, but at least 90 (with deviation requirements) is pretty on-point to prevent re-use issues if a third party is compromised. It's not perfect, but it's far better than nothing.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Nathan Minier wrote: This isn't an insider threat mitigation strategy. As I said, 30 days is a bit much, but at least 90 (with deviation requirements) is pretty on-point to prevent re-use issues if a third party is compromised. It's not perfect, but it's far better than nothing.
It is patchwork for someone who is too lazy to control the entire chain, and it is evil; it gives the impression of added security, where there isn't.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I disagree. There is no "control the entire chain" when a user can use the same password on my system as on a third party system, and I have no idea what precautions that system might have in place. Compared to the risk of compromise of credentials through third parties, the risk that an employee might keep a written ledger of passwords (or use a password manager) is much easier to accept.
As an SA or ISSO, I have no control over what passwords users have on other systems; but if I make them change it often enough I can reduce the risk of password reuse, and risk reduction is all that you can do in security. Not having password change requirements is frankly "lazy", as you are not only putting your system at risk, but any other that the user might have an account with.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Nathan Minier wrote: but if I make them change it often enough I can reduce the risk of password reuse
No, now you are increasing that risk. Januari01, February02, March03..
Nathan Minier wrote: and risk reduction is all that you can do in security
My world has to be black and white; either something can be trusted, or it can't. If it is outside my control, there will be no trust.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
That's not the password reuse I'm referring to.
Most users will use the same password on multiple systems. If system A has a more frequent password refresh period than system B, after that first refresh period they will be different from each other unless the user explicitly changes system B at the same time. However, most users will only change a password because they're prompted to, not because they had to for a different system, and they just end up tracking more passwords (again, why I advocate password managers).
Eddy Vluggen wrote: My world has to be black and white; either something can be trusted, or it can't. If it is outside my control, there will be no trust.
That's cool and great for dev work; but that viewpoint does not work for security modelling. Security models are built on people, which are more effectively tracked by statistical plotting than by binary behavior models.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Nathan Minier wrote: Most users will use the same password on multiple systems. If system A has a more frequent password refresh period than system B, after that first refresh period they will be different from each other unless the user explicitly changes system B at the same time.
So, by forcing the user to adapt to a predictable pattern, or find a way to game the system (as told by a co-worker, change the password four times, and it accepts the first, even if it is reused), you make things more secure?
So, one of us goes for a lubber, the other for sterilization 
Nathan Minier wrote: Security models are built on people, which are more effectively tracked by statistical plotting than by binary behavior models.
Now you're not building on people, but on a matrix of risc vs. damage. A leak plugged with duct-tape is still a leak.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
The level of mental gymnastics that you're going through to justify being too lazy to change a password is astounding. If you put that much effort into understanding the other side of the argument, you might have a shot at understanding threat modelling.
Eddy Vluggen wrote: So, one of us goes for a lubber, the other for sterilization
No, the only "sterile" computer is one that's powered down. I prefer my systems to be functional.
Eddy Vluggen wrote: Now you're not building on people, but on a matrix of risc vs. damage. A leak plugged with duct-tape is still a leak.
Sure, but that matrix is based on a continuum of behavior, not a fantasy binary existence. Your analogy is insipid BTW, your attitude is to not attempt to plug the leak at all.
Eddy Vluggen wrote: (as told by a co-worker, change the password four times, and it accepts the first, even if it is reused),
FYI both pam_cracklib and LAPS can be configured to flag an age on passwords, i.e. no reuse for a set time. Windows 2K+ can sen a minimum password age via GPO. If users can cycle their passwords back to original in your environment, then clearly your security people are out of their depth.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Nathan Minier wrote: The level of mental gymnastics that you're going through to justify being too lazy to change a password is astounding
Similar to the way you jump to a conclusion? I'd simply demand a different type of lock - never claimed to be against locking or passwords.
Nathan Minier wrote: your attitude is to not attempt to plug the leak at all.
We never discussed that part; but yes, if it leaks, I'd want a decent plug, not a 30 day rotating duct-tape.
Nathan Minier wrote: If users can cycle their passwords back to original in your environment, then clearly your security people are out of their depth.
Well, like you, they work with "real" people, and it is about controlling risks there - not about avoiding them
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
It would be nice if everyone had an embedded x509 hardware token, but that's simply not economically feasible for many organizations. Biometrics are still pretty sketchy and will be for a while yet. Passwords are simply a reality that need to be dealt with, and scoffing at management strategies for them doesn't help anyone.
Eddy Vluggen wrote: Well, like you, they work with "real" people, and it is about controlling risks there - not about avoiding them
Yeah, exactly my point.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Nathan Minier wrote: It would be nice if everyone had an embedded x509 hardware token, but that's simply not economically feasible for many organizations. Biometrics are still pretty sketchy and will be for a while yet.
If you go on a Dutch train you're already forced to use a hardware token.
Nathan Minier wrote: Passwords are simply a reality that need to be dealt with, and scoffing at management strategies for them doesn't help anyone.
There are safer options than having the plain username/password combo. Scoffing works by the way, and it was for the good of anyone to point out that the medical website I was using is unsafe. Now scoffing alone means you're being a dick - so I also made sure to explain the alternative.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
A_Griffin wrote: I'm not really a security expert
I'm not sure anyone really is.
It's my understanding that most major security breaches are not through guessing someone's password but through other security holes so I don't think these policies do any good at all.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
Not just gratuitous self-promotion (because that doesn't work well) but you could really try
my C'YaPass program (Users Hate Passwords (We're All Users): Never Memorize a Password Again[^]).
It's free, open source, and there is code for 4 major platforms (windows, web, android, ios).
The coolest thing in the latest version is that it remembers all those annoying password requirements* now.
*Add uppercase, add special character, length req
modified 8-Mar-18 8:40am.
|
|
|
|
|
Interesting article, thanks!
|
|
|
|
|
Thanks for checking the article out.
|
|
|
|
|
A_Griffin wrote: One of my clients
They are paying you to do a job; either do it with their requirements or don't get paid.
Have you heard of how many control systems get hacked because people didn't change default passwords or change them on a regular basis? It is not so much an issue in the U.S.A. where companies are required by federal law to maintain secure environments, but it is still a threat.
|
|
|
|
|
Changing default passwords is another matter entirely, and of curse it's a no-brainer. As for Quote: They are paying you to do a job; either do it with their requirements or don't get paid
I have a good relationship with my clients - we can speak freely with each other.
|
|
|
|
|
NIST has also changed its tune re: password change frequency, although I can't find their official policy document right now.
|
|
|
|
|
|
Yep, that's exactly the document I came across. I just couldn't find the relevant paragraph, so I opted not to send a link to a document of that size without being a little more specific.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
