How do I disable PCI Compliance?

[Ripper]

How do I disable admin password reset?
Really, I need this "feature" gone.

[Ripper]

Sorry, I should be more specific. I am talking about the software changing my login as admin every 90 days. I do not need, nor do I want this to happen.

[stevesh]

The general inclination here is to not answer questions like that one. It might make a difference if you let us know why you don't 'need' that feature. As you pointed out in the original thread title, it is a requirement for some certifications.

[RodG]

Sorry, I should be more specific. I am talking about the software changing my login as admin every 90 days. I do not need, nor do I want this to happen.

There are a couple of ways to do this. My current method of choice is the set the ZenCart database admin table so the 'pwd_last_change_date' is set several years into the future. I must stress that I do NOT do this on any live sites under my control. It is used on my development sites only. (Security reasons)

Having said that, whenever I'm greeted with that pesky 'please change your password' message I tend to cheat a little. I find it annoying to have to change my complex passwords into a different complex password, so what I tend to do is log into the database and change the 'pwd_last_change_date' to todays date, which effectively gives me another 90 days with the same password before I need to repeat the process (an annoyance I am prepared to live with, even though it'd be just as easy to make it not expire at all, as with my dev sites).

Please don't make this change lightly though. If your customers confidential data ever gets compromised because you have bypassed inbuilt security mechanisms you could be legally liable for any damages or losses caused.

Cheers
Rod

[Ripper]

How would customers' data be corrupted by not having the cart administrator need to change his or her password? I have no need to ever change my password. Not to mention, you can't use the last 5 passwords you ever used, it makes having to remember another password even more fun. My passwords are complex. I keep them in my head, where no one can get to them. If I have to keep changing the password, I will have to write it down or store it on my computer, making that password inherently unsafe.

[kobra]

You could change it 4-5 times reverting back to your preferred password in one go

[RodG]

How would customers' data be corrupted .

I said 'compromised', not 'corrupted'.

by not having the cart administrator need to change his or her password? .

In a perfect world there wouldn't be a problem. We don't live in a perfect world though, and people use weak (easily cracked) passwords, or they use the same password everywhere, or they'll share their passwords with other people. The list is endless...

Password policies have been developed and implemented out of the need to protect people from themselves.

I have no need to ever change my password. Not to mention, you can't use the last 5 passwords you ever used, it makes having to remember another password even more fun.

This is why I've adopted the method of changing the password expiration dates rather than the passwords themselves (on my dev sites). Password policies can be (are) a very debatable issue and no single policy will apply to all situations.

Although both you and I know the meaning of a 'complex password' and/or the reasons to change passwords on a 'regular' basis, the same can't be said for the typical computer user, who will be more than happy to run systems and servers with no protection at all if they could get away with it.

My passwords are complex. I keep them in my head, where no one can get to them. If I have to keep changing the password, I will have to write it down or store it on my computer, making that password inherently unsafe.

If I didn't sympathize with what you are stating I would never have provided you with *my* solution to this issue/argument, but don't expect this to ever change. The latest ZenCart releases have implemented these particular policies because it is required for PCI compliance. This is a case where we can't have it both ways, if we wish for Zen to be PCI compliant (why wouldn't we?) then the software must adhere to the set policies, regardless of our own thoughts on the matter. If a person is smart enough to know why the policies are put in place and take their own measures to mitigate the risks and proceed to bypass the policy itself, then the risk is all theirs. Nothing wrong with that, but you can't expect the software developers to NOT implement these policies because the *minority* would be doing the right thing as a matter of course. It is a case of catering for the majority that really do need some kind of protection against themselves.

You (and I) need to appreciate this fact that people need to be protected from themselves rather than complaining that it makes it more difficult for us than it needs to be. I can't imagine the state of the 'Net if we didn't do this.

You/I may not *like* these policies, but without them? Who knows.

Cheers
Rod