|
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.
|
|
|
|
|
You are right, to a point. I think two things: make passwords at least 16 chars long and change passwords maybe once a year.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
|
ask the clients IT dept to change your email to a forwarder to another email address on a sane system.
best is your own domain if you have one - if they moan about security you can honestly say you 100% control access.
Myself I registered a domain and pay the annual fees (domain, hosting) and it's only used for my own email (too lazy to do a page so website forever says "under construction.") For a few dollars a month handy coz I can add as many email addresses as I like (including temp for 1 time registration then remove to avoid spam), manage spam filters and even for testing apps that send emails.
Signature ready for installation. Please Reboot now.
|
|
|
|
|
Well, yes I do have my own domain (several, in fact) but I also have email addresses tied to a couple of clients.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
