Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
PCI Compliant Passwords
- Thread starter coorsman
- Start date
GAMicrosUser
MIS
We are about to upgrade our Micros systems to a new version that will require the same password policy. How have you guys handled this in a Micros environment. We have many locations so I can see this being a complex issue. Any feedback is appreciated.
Regards.
Regards.
Two words: "Compensating Controls"
There's always a way to appease the auditor with appeals. As long as no one knows this password (except techs), or can use it, you can still be compliant. Be creative while maintaining the "intent" of the requirements.
There's always a way to appease the auditor with appeals. As long as no one knows this password (except techs), or can use it, you can still be compliant. Be creative while maintaining the "intent" of the requirements.
USofAScott
MIS
Coorsman
Does RAL work on hardware that is not from Radiant. We are using 3rd party hardware with Aloha?
Does RAL work on hardware that is not from Radiant. We are using 3rd party hardware with Aloha?
- Thread starter
- #5
GAMicrosUser
MIS
Good responses so far, we have the settings for Micros PCI compliance. Most of them are in fact required settings to complete the upgrade to 4.9. I am just curious how others are managing the requirement for user passwords to expire and locking accounts after failed attempts.
We have a lot of stores and I can see this being a challenging issue on a daily basis with users locking themselves out and forgetting what the set their passwords to.
We have a lot of stores and I can see this being a challenging issue on a daily basis with users locking themselves out and forgetting what the set their passwords to.
yep, and the more complex the password is, the more likely they are to write it down which defeats the intent. And further, when they lock themselves out, how do you verify the person on the other end of the phone is who they say they are? Video? Voice recognition?
Supporting this is a daily struggle for all of us.
Supporting this is a daily struggle for all of us.
The fingerprint technology is a little amiss. And when you upgrade a MicrosDB the fingerprints have to be all captured again (they do not get upgraded).
Personally the PCI thing is a little overzealous. If you want to see card details, go straight for any interface (i.e to Fidelio PMS).
I believe the best systems dont need PCI compliance if you use a token and expect the CC software to handle the security. We have a lot of systems here that dont need to be PCI compliant as they do not capture or store the CC number. Micros is the only company that seems to capture the card.
I guess the word here is Integrated Eftpos. Integrating and passing a value that is was paid etc.
Personally the PCI thing is a little overzealous. If you want to see card details, go straight for any interface (i.e to Fidelio PMS).
I believe the best systems dont need PCI compliance if you use a token and expect the CC software to handle the security. We have a lot of systems here that dont need to be PCI compliant as they do not capture or store the CC number. Micros is the only company that seems to capture the card.
I guess the word here is Integrated Eftpos. Integrating and passing a value that is was paid etc.
GAMicrosUser
MIS
So glad to see that we are not alone with this. Our users have never had to manage passwords at the POS.
What really concerns me is also managing the admin passwords. They also must change when we do this upgrade. What happens if a user locks out their account, calls the help desk for assistance, and for some reason the help desk locks the admin account?
I have figured out how to handle it via db queries but it is such a clumsy process.
I have not found a way to configure the 3700 system to allow the admin accounts to keep a static password.
What really concerns me is also managing the admin passwords. They also must change when we do this upgrade. What happens if a user locks out their account, calls the help desk for assistance, and for some reason the help desk locks the admin account?
I have figured out how to handle it via db queries but it is such a clumsy process.
I have not found a way to configure the 3700 system to allow the admin accounts to keep a static password.
I don't think there is a way to set passwords to not expire. I also don't think you are allowed to use generic "admin" accounts to be compliant, so each help desk admin should have their own account and password.
If the admin gets locked out, then the SQL update is the easiest way to enable their account again.
When we upgraded to the version of Micros with these user/password requirements, we definitely saw an increase in the number of calls from managers getting locked out.
If the admin gets locked out, then the SQL update is the easiest way to enable their account again.
When we upgraded to the version of Micros with these user/password requirements, we definitely saw an increase in the number of calls from managers getting locked out.
Our method has been to keep the existing passwords and simply add training values for the current month. i.e. Support.10 for october, Support.11 for November. If it has not been changed you work backwards through the months to find the correct password.
If locked out of Micros you can ISQL / batch to remove the 'locked' status of the account you are trying to access. My personal resolution has been to use ISLQ to alter the SECURITY TYPE for the restaurant, unlock the account, and inject or use the basic login code for the user.
Once you are in you reset to advanced security, change the users login2 .
The biggest muck up for EDC is to change the dates of the computer . It disables the gateway if an incorrect / back date is transmitted to the gateway
If locked out of Micros you can ISQL / batch to remove the 'locked' status of the account you are trying to access. My personal resolution has been to use ISLQ to alter the SECURITY TYPE for the restaurant, unlock the account, and inject or use the basic login code for the user.
Once you are in you reset to advanced security, change the users login2 .
The biggest muck up for EDC is to change the dates of the computer . It disables the gateway if an incorrect / back date is transmitted to the gateway
- Status
Similar threads
- Locked
- Question