4 ms·

Unfortunately my company claims their credit card and electronic payment processing agreements require employee password to expire. If that’s actually true, th

by mint2 7y ago

Unfortunately my company claims their credit card and electronic payment processing agreements require employee password to expire. If that’s actually true, then most companies hands are tied until those payment agencies update their requirements.

sitharus 7y ago
This is true, PCI DSS still requires password expiry. The trick is figuring out the boundary of the systems that are subject to PCI.
- tatersolid 7y ago
  > This is true, PCI DSS still requires password expiry. We’ve been using a compensating control of “our password policy is exactly NIST SP 800-63B (2017) plus two more characters in Min length” for our PCI audits since the revision was published in 2017. It’s been accepted three times so far.
  - cortesoft 7y ago
    As always with PCI, it depends on your auditor.
    - AmericanChopper 7y ago
      Using NIST password guidelines as a compensating control has been accepted by every assessor I’ve dealt with (even the really bad ones). A compensating control must exceed the requirements of the control its compensating for, and the NIST rules clearly do. I’d say it has much more to do with how you write your compensating control worksheet rather than anything else. If you assessor is refusing to accept compensating controls, you should report them to the SSC, and then find a new assessor.
    - tatersolid 7y ago
      Yes, if you’re not actually doing the “compare password against breach lists” part of SP 800-63B regularly they likely won’t accept it. I hope forced expiry will be gone from next PCI revision anyway.
      - alanning 7y ago
        Do you happen to have a library/tool you could recommend that helps with this or did you develop something in-house? My startup is implementing most of the NIST rec’s with the help of projects like zxcvbn but we would like to also start doing breach list comparisons so figured I’d ask.
        djhn 7y ago
        H8mail on Github and the APIs it connects to.
        tatersolid 7y ago
        We use the NTLM version of the haveibeenowned lists plus a power shell script from https://github.com/MichaelGrafnetter/DSInternals/blob/master/Documentation/PowerShell/Test-PasswordQuality.md https://github.com/MichaelGrafnetter/DSInternals/blob/master...
  - tialaramex 7y ago
    Yes. When a policy is crazy, the Right Thing is to find out how to either alter that policy or obtain an authorised deviation from it as tatersolid describes. If you spend an hour a month on something that's required by policy and in your opinion shouldn't be, then six hours invested finding the person who sets that policy and explaining why it's a terrible idea may free up net six extra hours of your life within a year. That story where the guy comes down a mountain with a stone tablet with Ten Commandments carved into it is (a) a myth and (b) no kind of a way to set effective policy. People can't even agree on what his Ten Commandments were, let alone on following them.
- zamalek 7y ago
  I think we have it for one of the ISO compliances, too.
  - tialaramex 7y ago
    The ISO 27xxx standards in Information Security don't tell you how to do it, they tell you how to formalise what you decided to do (and how it can be monitored, audited, etc.). So the reason your ISO compliance forces you to do password rotation is that some twit added "password rotation" to the policies you decided you were going to implement. New task: Find the relevant policy and revise it citing the modern NIST guidance. Extra credit: Go through other policies that get in your way, figure out why they're in there and either you'll be reconciled to this annoyance in your life or you can revise the policy to not be a problem.
14 7y ago
I would love to know my companies reasoning. I work for a huge health care provider and everyone from care workers to the nurses in our office have to change our passwords each 6 weeks. Myself and others just keep the same passwords and increase the number at the end. Currently we keep getting these emails from IT telling us security threat level is high and don’t click links from unknown locations. The system is buggy to add to is all so people are constantly getting locked out and they call IT who helps change to another password. After having to do it so often so many times most of us just don’t care anymore. My password is kind of complex and in the middle I have a number that I just increase each time.
v7p1Qbt1im 7y ago
That‘s because these companies, and the regulation itself don‘t have security in mind. It‘s really only about compliance and liability avoidance. There is no incentive for change. Look what happened with Equifax.

by mint2 7y ago

sitharus 7y ago

This is true, PCI DSS still requires password expiry. The trick is figuring out the boundary of the systems that are subject to PCI.

tatersolid 7y ago
> This is true, PCI DSS still requires password expiry. We’ve been using a compensating control of “our password policy is exactly NIST SP 800-63B (2017) plus two more characters in Min length” for our PCI audits since the revision was published in 2017. It’s been accepted three times so far.
- cortesoft 7y ago
  As always with PCI, it depends on your auditor.
  - AmericanChopper 7y ago
    Using NIST password guidelines as a compensating control has been accepted by every assessor I’ve dealt with (even the really bad ones). A compensating control must exceed the requirements of the control its compensating for, and the NIST rules clearly do. I’d say it has much more to do with how you write your compensating control worksheet rather than anything else. If you assessor is refusing to accept compensating controls, you should report them to the SSC, and then find a new assessor.
  - tatersolid 7y ago
    Yes, if you’re not actually doing the “compare password against breach lists” part of SP 800-63B regularly they likely won’t accept it. I hope forced expiry will be gone from next PCI revision anyway.
    - alanning 7y ago
      Do you happen to have a library/tool you could recommend that helps with this or did you develop something in-house? My startup is implementing most of the NIST rec’s with the help of projects like zxcvbn but we would like to also start doing breach list comparisons so figured I’d ask.
      - djhn 7y ago
        H8mail on Github and the APIs it connects to.
      - tatersolid 7y ago
        We use the NTLM version of the haveibeenowned lists plus a power shell script from https://github.com/MichaelGrafnetter/DSInternals/blob/master/Documentation/PowerShell/Test-PasswordQuality.md https://github.com/MichaelGrafnetter/DSInternals/blob/master...
- tialaramex 7y ago
  Yes. When a policy is crazy, the Right Thing is to find out how to either alter that policy or obtain an authorised deviation from it as tatersolid describes. If you spend an hour a month on something that's required by policy and in your opinion shouldn't be, then six hours invested finding the person who sets that policy and explaining why it's a terrible idea may free up net six extra hours of your life within a year. That story where the guy comes down a mountain with a stone tablet with Ten Commandments carved into it is (a) a myth and (b) no kind of a way to set effective policy. People can't even agree on what his Ten Commandments were, let alone on following them.
zamalek 7y ago
I think we have it for one of the ISO compliances, too.
- tialaramex 7y ago
  The ISO 27xxx standards in Information Security don't tell you how to do it, they tell you how to formalise what you decided to do (and how it can be monitored, audited, etc.). So the reason your ISO compliance forces you to do password rotation is that some twit added "password rotation" to the policies you decided you were going to implement. New task: Find the relevant policy and revise it citing the modern NIST guidance. Extra credit: Go through other policies that get in your way, figure out why they're in there and either you'll be reconciled to this annoyance in your life or you can revise the policy to not be a problem.

14 7y ago

I would love to know my companies reasoning. I work for a huge health care provider and everyone from care workers to the nurses in our office have to change our passwords each 6 weeks. Myself and others just keep the same passwords and increase the number at the end. Currently we keep getting these emails from IT telling us security threat level is high and don’t click links from unknown locations. The system is buggy to add to is all so people are constantly getting locked out and they call IT who helps change to another password. After having to do it so often so many times most of us just don’t care anymore. My password is kind of complex and in the middle I have a number that I just increase each time.

v7p1Qbt1im 7y ago

That‘s because these companies, and the regulation itself don‘t have security in mind. It‘s really only about compliance and liability avoidance. There is no incentive for change. Look what happened with Equifax.