Password policy
-
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 :suss: 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
-
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 :suss: 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.
-
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 :suss: 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
-
One of my clients, with whom I have an email account set up, has a company policy on enforced password changes every month, which drives me nuts. I've tried to connive them that the received wisdom these days from security experts is that this is not a good idea - eg: The problems with forcing regular password expiry - NCSC Site[^] Time to rethink mandatory password changes | Federal Trade Commission[^] but as I'm not really a security expert myself perhaps I shouldn't be pushing this... anyway, they aren't listening to me.... but it's a pain in the derrierre .... am I right, or are they?
[NIST](http://nist.gov) has also changed its tune re: password change frequency, although I can't find their official policy document right now.
-
One of my clients, with whom I have an email account set up, has a company policy on enforced password changes every month, which drives me nuts. I've tried to connive them that the received wisdom these days from security experts is that this is not a good idea - eg: The problems with forcing regular password expiry - NCSC Site[^] Time to rethink mandatory password changes | Federal Trade Commission[^] but as I'm not really a security expert myself perhaps I shouldn't be pushing this... anyway, they aren't listening to me.... but it's a pain in the derrierre .... am I right, or are they?
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
-
One of my clients, with whom I have an email account set up, has a company policy on enforced password changes every month, which drives me nuts. I've tried to connive them that the received wisdom these days from security experts is that this is not a good idea - eg: The problems with forcing regular password expiry - NCSC Site[^] Time to rethink mandatory password changes | Federal Trade Commission[^] but as I'm not really a security expert myself perhaps I shouldn't be pushing this... anyway, they aren't listening to me.... but it's a pain in the derrierre .... am I right, or are they?
I just looked at this a few days ago. My employer makes us change it every 42 days and remembers the last 26 passwords! I suggested to the devops guy that we change it. He inherited it and is open to change. I found two links in reference to the PCI guidelines (as we need to be PCI compliant) that state that they can go as old as 90 days. So that is my suggestion. I also suggested that it doesn't remember 26 old passwords. We'll see if updates happen, but I feel your pain! Based on quick math, I'm about 40 passwords in at this job. [http://pcipolicyportal.com/blog/pci-compliance-password-requirements-best-practices-know/\](http://pcipolicyportal.com/blog/pci-compliance-password-requirements-best-practices-know/) [https://security.stackexchange.com/questions/161381/password-expiration-and-compliance-iso-nist-pci-etc\](https://security.stackexchange.com/questions/161381/password-expiration-and-compliance-iso-nist-pci-etc)
Hogan
-
One of my clients, with whom I have an email account set up, has a company policy on enforced password changes every month, which drives me nuts. I've tried to connive them that the received wisdom these days from security experts is that this is not a good idea - eg: The problems with forcing regular password expiry - NCSC Site[^] Time to rethink mandatory password changes | Federal Trade Commission[^] but as I'm not really a security expert myself perhaps I shouldn't be pushing this... anyway, they aren't listening to me.... but it's a pain in the derrierre .... am I right, or are they?
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.
-
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.
-
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.
-
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
-
One of my clients, with whom I have an email account set up, has a company policy on enforced password changes every month, which drives me nuts. I've tried to connive them that the received wisdom these days from security experts is that this is not a good idea - eg: The problems with forcing regular password expiry - NCSC Site[^] Time to rethink mandatory password changes | Federal Trade Commission[^] but as I'm not really a security expert myself perhaps I shouldn't be pushing this... anyway, they aren't listening to me.... but it's a pain in the derrierre .... am I right, or are they?
The customer is always rigght ......... or not!
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
-
[NIST](http://nist.gov) has also changed its tune re: password change frequency, although I can't find their official policy document right now.
-
So change your password every month to My_ridiculous_password_1 through My_ridiculous_password_12 and then start over from the beginning.
Wrong is evil and must be defeated. - Jeff Ello
Jörgen Andersson wrote:
My_ridiculous_password_1 through My_ridiculous_password_12
Where I am now had the setting so it wouldn't let you re-use the last 9 passwords until they realized that the majority of employees were just using My_easy_password_1 to My_easy_password_0 then starting over at 1. So the fix? Change it to not allow you to use the last 20 passwords! Bet you can't guess what changed.
-
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 :suss: 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.
-
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 :suss: 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
-
Jörgen Andersson wrote:
My_ridiculous_password_1 through My_ridiculous_password_12
Where I am now had the setting so it wouldn't let you re-use the last 9 passwords until they realized that the majority of employees were just using My_easy_password_1 to My_easy_password_0 then starting over at 1. So the fix? Change it to not allow you to use the last 20 passwords! Bet you can't guess what changed.
RJOberg wrote:
So the fix? Change it to not allow you to use the last 20 passwords! Bet you can't guess what changed.
The obvious solution is to not allow numbers at the end or start of a password. Of course that just leads to people using things like my1password, my2password, etc. So obviously you also have to require the first four characters of the password to be different each time as well.
-
One of my clients, with whom I have an email account set up, has a company policy on enforced password changes every month, which drives me nuts. I've tried to connive them that the received wisdom these days from security experts is that this is not a good idea - eg: The problems with forcing regular password expiry - NCSC Site[^] Time to rethink mandatory password changes | Federal Trade Commission[^] but as I'm not really a security expert myself perhaps I shouldn't be pushing this... anyway, they aren't listening to me.... but it's a pain in the derrierre .... am I right, or are they?
-
RJOberg wrote:
So the fix? Change it to not allow you to use the last 20 passwords! Bet you can't guess what changed.
The obvious solution is to not allow numbers at the end or start of a password. Of course that just leads to people using things like my1password, my2password, etc. So obviously you also have to require the first four characters of the password to be different each time as well.
Oh, there are many solutions: one of my favorites is to require a percentage of all letters to change to force the user to use a completely new password each time. Depending on how that is implemented, the user can just shift the entire password one character left or right and fool the entire mechanism. Mostly this is a game. It is "wily" network administrators against their own users who endeavor to circumvent the network administrators. You'll notice, while being adversaries in this battle, both are missing the true enemy lurking trying to find a way in!