The auditor requesting the following information would have to be done in two weeks
- A list of current usernames and plain-text passwords for all user accounts on all servers
- A list of all password changes for the past six months, again in plain-text
- A list of "every file added to the server from remote devices" in the past six months
- The public and private keys of any SSH keys
- An email sent to him every time a user changes their password, containing the plain text password
We're running red hat linux 5/6 and centos 5 boxes with ldap authentication.
As far as i'm aware, everything on that list is either impossible or incredibly difficult to get, but if i don't provide this information we face losing access to our payments platform and losing income during a transition period as we move to a new service. Is there any way to solve or fake this information?
The only way i can think to get all the plain text passwords is to get everyone to reset their password and to make a note of what they've set it to This doesn't solve the problem of the last six months of password changes because i can't retroactively log this type of stuff the same goes for logging all remote files
Getting all of the public and private ssh keys is possible (though annoying), since we have just a few users and computers. What's the easiest way to do this?
I've explained to him many times that things that he wants are impossible In response to my concerns he responded with the following email
I have over 10 years experience in security auditing and a full understanding of the redhat security methods, so I suggest you check your facts about what is and isn't possible. You say no company could possibly have this information but I have performed hundreds of audits where this information has been readily available. All [generic credit card processing provider] clients are required to conform with our new security policies and this audit is intended to ensure those policies have been implemented* correctly.
*The "new security policies" were introduced two weeks before our audit, and the six months historical logging was not required before the policy changes.
In short, I need;
- A way to "fake" six months worth of password changes and make it look valid
- A way to "fake" six months of inbound file transfers
- An easy way to collect all the SSH public and private keys being used
If we fail the security audit we lose access to our card processing platform (a critical part of our system) and it would take a good two weeks to move somewhere else. How screwed am i?
Update 1 (Sat 23rd)
Thanks for all your responses it gives me great relief to know this is not standard practice
I'm planning to answer a letter by e-mail explaining the situation to him As many of you pointed out we have to comply with pci which expressly states that we shouldn't have any way to access plain-text passwords I'll send you the email when i've finished writing Unfortunately i don't think he's just testing us; these things are in the company's official security policy now. I have, however, set the wheels in motion to move away from them and onto paypal for the time being.
Update 2 (Sat 23rd)
This is the email i've drafted out, any suggestions for stuff to add/remove/change?
Unfortunately there is no way for us to provide you with some of the information requested, mainly plain-text passwords, password history, SSH keys and remote file logs. Not only are these things technically impossible, but also being able to provide this information would be both a against PCI Standards, and a breach of the data protection act.
To quote the PCI requirements,
8.4 Render all passwords unreadable during transmission and storage on all system components using strong cryptography.
I can provide you with a list of usernames and hashed passwords used on our system, copies of the SSH public keys and authorized hosts file (This will give you enough information to determine the number of unique users can connect to our servers, and the encryption methods used), information about our password security requirements and our LDAP server but this information may not be taken off site. I strongly suggest you review your audit requirements as there is currently no way for us to pass this audit while remaining in compliance of PCI and the Data Protection act.
I'll take a conversation with our cto and our account manager and i'm hoping the cto can confirm that this information is not available I'll also contact the pci security standards council to explain what he wants from us
Update 3 (26th)
Here are some emails we exchanged;
RE: my first email;
As explained, this information should be easily available on any well maintained system to any competent administrator. Your failure to be able to provide this information leads me to believe you are aware of security flaws in your system and are not prepared to reveal them. Our requests line up with the PCI guidelines and both can be met. Strong cryptography only means the passwords must be encrypted while the user is inputting them but then they should be moved to a recoverable format for later use.
I see no data protection issues for these requests, data protection only applies to consumers not businesses so there should be no issues with this information.
Just, what, I, can't, even...
"Strong cryptography only means the passwords must be encrypted while the user is inputting them but then they should be moved to a recoverable format for later use."
I'm gonna frame it and hang it on the wall
I was tired of being diplomatic and directed him to this thread to show him the response i got
Providing this information DIRECTLY contradicts several requirements of the PCI guidelines. The section I quoted even says
storage(Implying to where we store the data on the disk). I started a discussion on ServerFault.com (An on-line community for sys-admin professionals) which has created a huge response, all suggesting this information cannot be provided. Feel free to read through yourself
We have finished moving over our system to a new platform and will be cancelling our account with you within the next day or so but I want you to realize how ridiculous these requests are, and no company correctly implementing the PCI guidelines will, or should, be able to provide this information. I strongly suggest you re-think your security requirements as none of your customers should be able to conform to this.
(I'd actually forgotten I'd called him an idiot in the title, but as mentioned we'd already moved away from their platform so no real loss.)
And in his response he tells me that apparently none of you know what you're talking about
I read in detail through those responses and your original post, the responders all need to get their facts right. I have been in this industry longer than anyone on that site, getting a list of user account passwords is incredibly basic, it should be one of the first things you do when learning how to secure your system and is essential to the operation of any secure server. If you genuinely lack the skills to do something this simple I'm going to assume you do not have PCI installed on your servers as being able to recover this information is a basic requirement of the software. When dealing with something such as security you should not be asking these questions on a public forum if you have no basic knowledge of how it works.
I would also like to suggest that any attempt to reveal me, or [company name] will be considered libel and appropriate legal action will be taken
Key idiotic points if you missed them.
- He's been a security auditor longer than anyone else on here has (He's either guessing, or stalking you)
- Being able to get a list of passwords on a UNIX system is 'basic'
- PCI is now software
- People shouldn't use forums when they're not sure of security
- Posing factual information (to which I have email proof) online is libel
The pci ssc has responded and is investigating him and the company We have now switched to paypal so we know that it's safe I'm gonna wait for pci to come back to me first but i'm worried that they might be using this security practices internally If so, i think it is a major concern for us as all our card processing ran through them. If they'd done that internally i think the only responsible thing would be to inform our customers
I'm hoping when pci realizes how bad it is they'll examine the whole company and the system but i'm not sure
So now we've moved away from their platform, and assuming it will be at least a few days before pci get back to me, any inventive suggestions for how to troll him a bit? =)
Once i've got clearance from my legal guy (i highly doubt any of this is actually libel but i wanted to double check) i'll publish the company name, his name and email, and if you wish you can contact him and explain why you don't understand the basics of linux security like how to get a list of all the ldap users passwords.
My legal guy suggested revealing the company would probably cause more problems than needed I can say that although this is not a major provider they have less than 100 clients using this service We originally started using them when the site was tiny and running on a little vps, and we didn't want to go through all the effort of getting pci (we used to redirect to their frontend, like paypal standard). But when we moved to directly processing cards (including getting pci, and common sense), the devs decided to keep using the same company just a different api. The company is located in birmingham uk so i would highly doubt anyone here will be affected
You should first not capitulate He's not only an idiot but he's dangerously wrong In fact, releasing this information would violate the PCI standard (which is what I'm assuming the audit is for since it's a payment processor) along with every other standard out there and just plain common sense. This would also expose your company to all sorts of liabilities
The next thing i'd do is send an email to your boss saying he needs to get corporate counsel involved to determine the legal exposure the company would be facing by proceeding with this action
This last bit is up to you, but I would contact VISA with this information and get his PCI auditor status pulled.