A security auditor for our servers has demanded the following within 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. Any suggestions for how I can 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 make a note of what they set it to. That doesn't solve the problem of the past six months of password changes, because I can't retroactively log that sort of stuff, the same goes for logging all the remote files.

Getting all of the public and private SSH keys is possible (though annoying), since we have just a few users and computers. Unless I've missed an easier way to do this?

I have explained to him many times that the things he's asking for 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 isn't standard practice.

I'm currently planning out my email response to him explaining the situation. As many of you pointed out, we have to comply with PCI which explicitly states we shouldn't have any way to access plain-text passwords. I'll post the email when I've finished writing it. 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?

Hi [name],

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 will be CC'ing in the company's CTO and our account manager, and I'm hoping the CTO can confirm this information is not available. I will also be contacting the PCI Security Standards Council to explain what he's requiring 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 going to frame that and put it on my wall.

I got fed up 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 states 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


PCI SSC have responded and are investigating him and the company. Our software has now moved onto PayPal so we know it's safe. I'm going to wait for PCI to get back to me first but I'm getting a little worried that they might have been using these security practices internally. If so, I think it is a major concern for us as all our card processing ran through them. If they were doing this internally I think the only responsible thing to do would be to inform our customers.

I'm hoping when PCI realize how bad it is they will investigate the entire company and 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.

Little update:

My "legal guy" has suggested revealing the company would probably cause more problems than needed. I can say though, this is not a major provider, they have less 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 based in the Birmingham, UK area so I'd highly doubt anyone here will be affected.

  • 528
    You have two weeks to deliver him the information, and it takes two weeks to move to somewhere else who can process credit cards. Don't bother - make the decision to move now and abandon the audit.
    – Scrivener
    Commented Jul 22, 2011 at 22:54
  • 181
    Please, update us on what happens with this. I've got it favorited to see how the auditor gets spanked. =) If I know you, email me at the address in my profile.
    – Wesley
    Commented Jul 22, 2011 at 23:30
  • 166
    He must be testing you to see if you're really that stupid. Right? I hope so... Commented Jul 23, 2011 at 0:05
  • 215
    I'd want to know some references for other companies he's audited. If for no other reason than to know who to avoid. Plaintext passwords...really? Are you sure this guy's really not a black hat and social engineering stupid companies into handing over their user passwords for months? Because if there are companies doing this with him this is a GREAT way to just hand the keys over... Commented Jul 23, 2011 at 0:56
  • 339
    Any sufficiently advanced incompetence is indistinguishable from malice Commented Jul 24, 2011 at 10:11

31 Answers 31


First, DON'T capitulate. He is not only an idiot but 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. It would also expose your company to all sorts of liabilities.

The next thing I would 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.

  • 325
    You beat me to it! This is an illegal request. Get a PCI QSA to audit the processor's request. Get him on a phone call. Circle the wagons. "Charge for the guns!"
    – Wesley
    Commented Jul 22, 2011 at 23:29
  • 111
    "get his PCI auditor status pulled" I don't know what that means... but whatever authority this clown has (the auditor) obviously came from a wet cracker jack box and needs to get revoked. +1
    – WernerCD
    Commented Jul 23, 2011 at 0:53
  • 156
    This is all assuming that this fellow is actually a legitimate auditor... he sounds awfully suspicious to me.
    – Reid
    Commented Jul 23, 2011 at 1:30
  • 37
    I agree -- suspicious auditor, or he's a legitimate auditor seeing if you're stupid enough to do any of these things. Ask why he needs this information. Just consider the password, which should never be plain text, but should be behind some one way encryption (hash). Maybe he has some legitimate reason, but with all his "experience" he should be able to help you get the necessary information.
    – vol7ron
    Commented Jul 23, 2011 at 3:09
  • 28
    Why is this dangerous? A list of all plain text passwords - there should be none. If the list is not empty, he has a valid point. Same goes on for msot things. If you dont have them because they are not there say. Remote files added - that is part of auditiing. Dont know - start putting in a system that knows.
    – TomTom
    Commented Jul 23, 2011 at 5:17

As someone who has been through the audit procedure with Price Waterhouse Coopers for a classified government contract, I can assure you, this is totally out of the question and this guy is insane.

When PwC wanted to check our password strength they:

  • Asked to see our password strength algorithms
  • Ran test units against our algorithms to check that they would deny poor passwords
  • Asked to see our encryption algorithms to ensure that they couldn't be reversed or un-encrypted (even by rainbow tables), even by someone who had full access to every aspect of the system
  • Checked to see that previous passwords were cached to ensure that they couldn't be re-used
  • Asked us for permission (which we granted) for them to attempt to break into the network and related systems using non-social engineering techniques (things like xss and non-0 day exploits)

If I had even hinted that I could show them what the users passwords were over the last 6 months, they would have shut us out of the contract immediately.

If it were possible to provide these requirements, you would instantly fail every single audit worth having.

Update: Your response email looks good. Far more professional than anything I would have written.

  • 129
    +1. Looks like sensible quesstions that should NOT BE ANSWERABLE. If you can answer them you have a stupid security issue at hand.
    – TomTom
    Commented Jul 23, 2011 at 5:18
  • 9
    even by rainbow tables doesn't that rule out NTLM? I mean, it's not salted... AFAICR MIT Kerberos didn't encrypt or hash the active passwords, don't know what's current status Commented Jul 23, 2011 at 16:45
  • 9
    @Hubert - we weren't using NTLM or Kerberos as pass-through authentication methods were banned and the service wasn't integrated with active directory anyway. Otherwise we also couldn't show them our algorithms either (they're built into the OS). Should have mentioned - this was application-level security, not an OS level audit. Commented Jul 23, 2011 at 21:59
  • 4
    @tandu - that's what the specifications for the level of classification stated. It's also fairly common to stop people from re-using their last n passwords, because it stops people from just cycling through two or three commonly used passwords, which is just as insecure as using the same common password. Commented Jul 25, 2011 at 23:39
  • 13
    @Slartibartfast: but having a mean to know the plain text of the password means the attacker could just as well break into your database and retrieves everything in plain sight. As for protection against using similar password, that can be done in javascript in the client side, when the user is attempting to change password, also ask the old password and do similarity comparison with the old password before posting the new password to the server. Granted, it can only prevent reuse from 1 last password, but IMO the risk of storing password in plaintext is much more.
    – Lie Ryan
    Commented Aug 2, 2011 at 14:15

Honestly, it sounds like this guy (the auditor) is setting you up. If you give him the information he's asking for, you've just proven to him that you can be socially engineered to give up critical internal information. Fail.

  • 12
    also, have you considered a third-party payment processor, like authorize.net? the company i work for does very large amounts of credit card transactions through them. we don't have to store any of the customer payment info - authorize.net manages that - so there's no audit of our systems to complicate things.
    – anastrophe
    Commented Jul 22, 2011 at 23:42
  • 198
    this is exactly what I thought was happening. Social engineering is probably the easiest way to get this info and I think he's testing that loophole. This guy is either very intelligent or very dumb Commented Jul 23, 2011 at 0:08
  • 5
    This position is at least the most reasonable first step. Tell him you would be breaking laws/rules/whatever by doing any of it, but that you appreciate his guile.
    – michael
    Commented Jul 23, 2011 at 2:59
  • 52
    Dumb question: is “setting up” acceptable in this situation? Common logic tells me an audit process should not be made of “tricks”.
    – Agos
    Commented Jul 23, 2011 at 21:04
  • 25
    @Agos: I worked at a place a few years ago that hired an agency to do an audit. Part of the audit included calling random people in the company with the "<CIO> asked me to call you and get your login credentials so that I can <do something>." Not only were they checking to see that you wouldn't actually give up credentials, but once you hung up on them you were supposed to immediately call <CIO> or <Security Admin> and report the interchange.
    – Toby
    Commented Jul 28, 2011 at 12:04

I've just spotted you're in the UK, which means that what he's asking you to do is to break the law (the Data Protection Act in fact). I'm in the UK too, work for a large heavily-audited company and know the law and common practices around this area. I'm also a very nasty piece of work who will happily curb-stamp this guy for you if you like just for the fun of it, let me know if you'd like help ok.

  • 35
    Assuming there's any personal information on those servers, I think handing over /all/ of the credentials for access in plain text to someone with this level of demonstrated incompetence would be a clear breach of Principle 7... ("Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data.") Commented Jul 23, 2011 at 15:18
  • 6
    I think it's a fair assumption -- if you're storing payment information, you're probably also storing contact information for your users. If I were in the OP's position, I'd see "what you're asking me to do not only breaks policy and contractual obligations [to comply with PCI], but is also illegal" as a stronger argument than just mentioning policy and PCI. Commented Jul 23, 2011 at 18:25
  • 4
    @Jimmy why would a password not be personal data?
    – robertc
    Commented Jul 24, 2011 at 20:45
  • 11
    @Richard, you do know it was a metaphor right?
    – Chopper3
    Commented Jul 28, 2011 at 9:34
  • 9
    @Chopper3 Yes, I still think that it's inappropriate. Plus, I'm countering AviD. Commented Jul 28, 2011 at 9:38

You are being socially engineered. Either its to 'test you' or its a hacker posing as a auditor to get some very useful data.

  • 8
    Why isn't this the top answer? Does that say something about the community, the ease of social engineering, or am I missing something fundamental?
    – Paul
    Commented Jul 26, 2011 at 22:31
  • 189
    never attribute to malice what can be attributed to ignorance
    – aldrinleal
    Commented Jul 26, 2011 at 23:52
  • 15
    Attributing all those requests to ignorance when the auditor claims to be a professional, though, stretches the imagination a little.
    – Thomas K
    Commented Jul 27, 2011 at 16:24
  • 14
    The problem with this theory is that, even if he "fell for it" or "failed the test," he couldn't give him the information because it's impossible.....
    – eds
    Commented Jul 28, 2011 at 1:03
  • 4
    My best guess is 'serious social engineering' too (is it a coincidence the new Kevin Mitnick book is coming out soon?), in which case your payment firm will be surprised (have you checked with them about this 'audit' yet?). The other option is a very rookie auditor with no linux knowledge who tried bluffing and is now digging her/himself in deeper, deeper and deeper. Commented Jul 28, 2011 at 13:57

I am seriously concerned about OPs lack of ethical problem solving skills and the server fault community ignoring this blatant breach of ethical conduct.

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

Let me be clear on two points:

  1. It is never appropriate to falsify data during the course of normal business.
  2. You should never divulge this kind of information to anyone. Ever.

It is not your job to falsify records. It is your job to make sure that any necessary records are available, accurate, and secure.

The community here at Server Fault must treat these kinds of questions as the stackoverflow site treats "homework" questions. You can not address these issues with only a technical response or ignore the violation of ethical responsibility.

Seeing so many high-rep users replies here in this thread and no mention of the ethical implications of the question saddens me.

I would encourage everyone to read the SAGE System Administrators' Code of Ethics.

BTW, your security auditor is an idiot, but that does not mean you need to feel pressure to be unethical in your work.

Edit: Your updates are priceless. Keep your head down, your powder dry, and don't take (or give) any wooden nickels.

  • 54
    I disagree. The "auditor" was bullying OP into divulging information that would undermine the entire IT security of the organization. Under no circumstances should OP generate those records and provide them to anyone. OP should not fake records; they can easily be seen to be fake. OP should explain to higher-ups why the security auditors demands are a threat either through malicious intentions or utter incompetence (email passwords in plaintext). OP should recommend immediate termination of the security auditor and a full investigation into other activities of the former auditor.
    – dr jimbob
    Commented Jul 25, 2011 at 15:01
  • 23
    dr jimbob, I think you are missing the point: "OP should not fake records; they can easily be seen to be fake." is still an unethical position as you are suggesting he should only falsify data when it cannot be distinguished from true data. Sending false data is unethical. Sending passwords of your users to a third party is negligent. So we agree that something needs to be done about this situation. I am commenting on the lack of critical ethical thinking in solving this problem. Commented Jul 25, 2011 at 15:22
  • 18
    I disagreed with the "It is your job to make sure those records are available, accurate, and secure." You have an obligation to keep your system secure; unreasonable requests (like store & share plaintext passwords) should not be done if they compromise the system. Storing, recording, and sharing plaintext passwords is a major breach of trust with your users. It is a big red flag security threat. The security audit can and should be done without exposing plaintext passwords/ssh private keys; and you should let the higher ups know and resolve the issue.
    – dr jimbob
    Commented Jul 25, 2011 at 17:06
  • 13
    dr jimbob, I feel that we are two ships passing in the night. I agree with everything you are saying; I must not have articulated these points clearly enough. I will revise my initial response above. I relied too heavily on the context of the thread. Commented Jul 26, 2011 at 21:17
  • 4
    @Joseph Kern, I didn’t read the OP in the same manner as yourself. I read it more as how can I produce six months of data we never kept. Certainly, I agree, that most ways of trying to meet this requirement would be fraudulent. However, were I to take my password database and extract timestamps for the last 6 months I could create a record of what changes were still preserved. I consider that ‘faking’ data as some data has been lost.
    – user179700
    Commented Jul 31, 2011 at 23:30

You can't give him what you want, and attempts to "fake" it are likely to come back to bite you in the arse (possibly in legal ways). You either need to appeal up the chain of command (it's possible this auditor's gone rogue, although security audits are notoriously idiotic -- ask me about the auditor that wanted to be able to access an AS/400 via SMB), or get the hell out from underneath these onorous requirements.

They're not even good security -- a list of all plaintext passwords is an incredibly dangerous thing to ever produce, regardless of the methods used to safeguard them, and I'll bet this bloke will want them e-mailed in plain-text. (I'm sure you know this already, I just have to vent a little).

For shits and giggles, ask him directly how to execute his requirements -- admit you don't know how, and would like to leverage his experience. Once you're out and gone, a response to his "I have over 10 years experience in security auditing" would be "no, you have 5 minutes of experience repeated hundreds of times".

  • 11
    ...an auditor that wanted access to an AS/400 via SMB?...why? Commented Jul 23, 2011 at 0:27
  • 12
    A much repeated hassle I've had with PCI compliance companies is arguing against blanket ICMP filtering, and only blocking echo. ICMP is there for a very good reason, but it's next to impossible to explain that to the numerous 'working from a script' auditors.
    – Twirrim
    Commented Jul 23, 2011 at 2:38
  • 53
    @BartSilverstrim Probably a case of check-list auditing. As an auditor once told me -- Why did the auditor cross the road? Because that's what they did last year.
    – Scott Pack
    Commented Jul 23, 2011 at 2:44
  • 13
    I know it's doable, the real "WTF?" was the fact that the auditor considered that the machine was vulnerable to attacks via SMB until he could connect via SMB...
    – womble
    Commented Jul 23, 2011 at 23:03
  • 21
    "You have 5 minutes of experience repeated hundreds of times" --- ooooh, that's going straight into my quote collection! :D Commented Aug 31, 2016 at 18:56

No auditor should fail you if they find a historical problem that you've now fixed. In fact, that's evidence of good behaviour. With that in mind, I suggest two things:

a) Do not lie or make stuff up. b) Read your policies.

The key statement for me is this one:

All [generic credit card processing provider] clients are required to conform with our new security policies

I bet that there's a statement in those policies saying passwords cannot be written down and cannot be passed to anyone other than the user. If there is, then apply those policies to his requests. I suggest handling it like this:

  • A list of current usernames and plain-text passwords for all user accounts on all servers

Show him a list of usernames, but do not allow them to be taken away. Explain that giving plain text passwords is a) impossible as it's one-way, and b) against policy, which he is auditing you against, so therefore you won't obey.

  • A list of all password changes for the past six months, again in plain-text

Explain that this was not historically available. Give him a list of recent password change times to show that this is now being done. Explain, as above, that passwords will not be provided.

  • A list of "every file added to the server from remote devices" in the past six months

Explain what is and is not being logged. Provide what you can. Do not provide anything confidential, and explain by policy why not. Ask if your logging needs to be improved.

  • The public and private keys of any SSH keys

Look at your key management policy. It should state that private keys are not allowed out of their container and have strict conditions of access. Apply that policy, and do not allow access. Public keys are happily public and can be shared.

  • An email sent to him every time a user changes their password, containing the plain text password

Just say no. If you have a local secure log server, allow him to see that this is being logged in situ.

Basically, and I'm sorry to say this, but you have to play hardball with this guy. Follow your policy exactly, do not deviate. Do not lie. And if he fails you for anything that is not in policy, complain to his seniors at the company who sent him. Collect a paper trail of all this to prove that you have been reasonable. If you break your policy you are at his mercy. If you follow them to the letter, he will end up being sacked.

  • 30
    Agreed, this is like one of those crazy reality shows, where a car service guy drives your car off a cliff or something equally unbelievable. I would say to the OP, prepare your resumé and leave, if the actions above don't work out for you. This is clearly a ridiculous and terrible situation. Commented Jul 23, 2011 at 10:30
  • 7
    Wish I could up-vote this +1,000,000. While most of the answers here pretty much say the same thing, this one is much more thorough. Great work, @Jimmy!
    – Iszi
    Commented Jul 24, 2011 at 19:42

Yes, the auditor is an idiot. However, as you know, sometimes idiots are placed in positions of power. This is one of those cases.

The information he requested has zero bearing on the current security of the system. Explain to the auditor that you're using LDAP for authentication and that the passwords are stored using a one-way hash. Short of doing a brute-force script against the password hashes (which could take weeks (or years), you will not be able to provide the passwords.

Likewise the remote files - I'd like to hear, perchance, how he thinks you ought to be able differentiate between files created directly on the server and a file that is SCPed to the server.

As @womble said, don't fake anything. That will do no good. Either ditch this audit and fine another broker, or find a way to convince this "professional" that his cheese has slid off of his cracker.

  • 68
    +1 for "...that his cheese has slid off of his cracker." That's a new one to me! Commented Jul 23, 2011 at 21:36
  • 3
    "The information he requested has zero bearing on the current security of the system." <- I'd actually say it has lots of bearing on the security. :P
    – Ishpeck
    Commented Jul 27, 2011 at 3:39
  • 2
    (which could take weeks (or years) I forget where, but I found this app online that would estimate how long it'd take to brute-force your password. I don't know what the brute-force or hashing algorithms it assumed were, but it estimated something like 17 trillion years for most of my passwords... :) Commented Jul 29, 2011 at 5:11
  • 69
    @Carson: the online app I found to estimate password strength had a different (and possibly more accurate) approach: for every password, it returned "Your password is insecure - you just typed it into an untrusted web page!"
    – Jason Owen
    Commented Jul 29, 2011 at 5:49
  • 3
    @Jason oh no, you're right! Commented Jul 29, 2011 at 6:03

Have your "security auditor" point to any text from any of these documents that have his requirements and watch as he struggles to come up with an excuse and eventually excuses himself to never be heard from again.

  • 12
    Agree. Why? is a valid question is a circumstance like this. The auditor should be able to provide documentation of the business/operational case for his requests. You can say to him "Put yourself in my position. This is the sort of request I would expect of someone attempting to set up an intrusion.".
    – jl.
    Commented Jul 27, 2011 at 13:46

WTF! Sorry but that's my only reaction to this. There are no audit requirements I have ever heard of that require a plaintext password, let alone feeding them the passwords as they change.

1st, ask him to show you the requirement that you provide that.

2nd, if this is for PCI (which we all assume since it's a payment system question) go here: https://www.pcisecuritystandards.org/approved_companies_providers/qsa_companies.php and get a new auditor.

3rd, follow what they said above, contact your management and have them contact the QSA company he is working with. Then immediately get another auditor.

Auditors audit system states, standards, processes, etc. They have no need to have any information that provides them access to systems.

If you would like any recommended auditors or alternate colo's that work closely with auditors contact me and I'd be happy to provide references.

Good luck! Trust your gut, if something seems wrong it probably is.


There is no legitimate reason for him to know the password and have access to the private keys. What he requested would give him the ability to impersonate any of your clients at any point in time and siphon as much money as he wants, without any way to detect it as a possible fraudulent transaction. It'll be exactly the type of security threats he's supposed to audit you for.

  • 2
    Come on, surely this is the point of the audit, social engineering??? 21 up-votes for this?!?
    – ozz
    Commented Jul 29, 2011 at 8:10
  • 20
    An audit consist of an official inspection of the security procedures and whether they are according to the established rules. It would be like the fire inspector coming to verify that you have all the necessary fire extinguishers, and the doors and windows or your restaurant can be opened according to the fire code. You wouldn't expect the fire inspector to try putting the restaurant on fire, would you? Commented Jul 30, 2011 at 3:20
  • 10
    This sounds more like setting up incendiary devices around the restaurant and giving the auditor remote triggers to them and promising to keep them up to date.
    – XTL
    Commented Mar 20, 2012 at 13:50

Notify management that the Auditor has requested that you breech your security policies, and that the request is illegal. Suggest that they may want to dump the present auditing firm and find a legitimate one. Call the police and turn the auditor in for requesting illegal information (in the UK). Then call the PCI and turn in the Auditor for their request.

The request is akin to asking you do go murder someone at random and hand over the body. Would you do that? or would you call the cops and turn them in?

  • 8
    Why not just say you can't provide the information because it violates you security policy. Get your tick in the box and pass the audit ?
    – user9517
    Commented Jul 23, 2011 at 13:49
  • 10
    Although the murder analogy might be a bit too far, you are correct that this "auditor" is breaking the law, and should be reported to your boss, the police and PCI Commented Jul 27, 2011 at 16:48

Respond with a lawsuit. If an auditor is asking for plain-text passwords (come on now, it's not that hard to bruteforce or crack weak password hashes), they probably lied to you about their credentials.

  • 10
    I would also see it as malpractice, depending on the locale there are probably laws around this too.
    – AviD
    Commented Jul 27, 2011 at 8:23

Just a tip with regards to how you word your response:

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...

I would rephrase this to avoid getting into a discussion about technical feasibility. Reading the awful initial e-mail sent by the auditor, it looks like this is someone who can pick on details that are not related to the main problem, and he might argue that you could save passwords, log logins, etc. So either say:

... Due to our strict security policies, we have never logged passwords in plain text. Therefore, it will be technically impossible to provide this data.


... Not only would we be significantly lowering our internal security level by complying to your request, ...

Good luck, and keep us posted how this ends!


At the risk of continuing the rush of high-rep users jumping in on this question, here are my thoughts.

I can kind of vaguely see why he wants the plaintext passwords, and that's to judge the quality of the passwords in use. It's a crap way to go about that, most auditors I know will accept the crypted hashes and run a cracker to see what kind of low-hanging fruit they can pull out. All of 'em will go over the password-complexity policy and review what safeguards are in place to enforce that.

But you have to deliver some passwords. I suggest (though I think you may have already done this) asking him what the goal of the plaintext password delivery is. He said it is to validate your compliance versus security policy, so get him to give you that policy. Ask him if he'll accept that your password complexity regime is robust enough to prevent users from setting their password to P@55w0rd and have provably been in place for the 6 months in question.

If he pushes it, you may have to admit that you can't deliver plaintext passwords since you're not set up to record them (what with it being a major security failing), but can endeavor to so in the future if he requires direct verification that your password policies are working. And if he wants to prove it, you'll happily provide the crypted password database for him (or you! Show willing! It helps!) to run a cracking pass over.

The "remote files" can likely be pulled out of the SSH logs for SFTP sessions, which is what I suspect he's talking about. If you don't have 6 months worth of syslogging, this'll be hard to produce. Is using wget to pull a file from a remote server while logged in via SSH considered a 'remote file transfer'? Are HTTP PUTs? Files created from clipboard text in the remote-user's terminal window? If anything, you can pester him with these edge-cases to get a better feel for his concerns in this area and perhaps instil the "I know more about this than you do" feeling, as well as what specific technologies he's thinking about. Then extract what you can out of logs and archived logs on backups.

I got nothing on the SSH keys. The only thing I can think of is that he's checking for passwordless keys for some reason, and maybe crypto strength. Otherwise, I got nothing.

As for getting those keys, harvesting at least the public keys is easy enough; just troll the .ssh folders looking for them. Getting the private keys will involve donning your BOFH hat and harumping at your users to the tune of, "Send me your public and private SSH key-pairs. Anything I don't get will be purged from the servers in 13 days," and if anyone squawks (I would) point 'em at the security audit. Scripting is your friend here. At minimum it'll cause a bunch of password-less keypairs to get passwords.

If he still insists on "plain-text passwords in email" at least subject those emails to GPG/PGP encryption with his own key. Any security auditor worth his salt should be able to handle something like that. That way if the passwords leak, it'll be because he let 'em out, not you. Yet another litmus test for competence.

I have to agree with both Zypher and Womble on this one. Dangerous idiot with dangerous consequences.

  • 1
    No evidence of idiocy. No evidence that the OP has formally said no I cannot provide this information. Surely if you can provide this information you will fail the audit.
    – user9517
    Commented Jul 23, 2011 at 13:04
  • 2
    @Iain Which is why socially engineering the security auditor to extract what he's really after is so important at this juncture.
    – sysadmin1138
    Commented Jul 23, 2011 at 13:28
  • 13
    I disagree with giving anything to this clearly unsecure individual.
    – Kzqai
    Commented Jul 23, 2011 at 23:17
  • @Tchalvak: no evidence of 'unsecure' or 'idiot'.
    – user9517
    Commented Jul 24, 2011 at 9:19
  • 2
    Not a high rep user, but my personal feeling for your answer is: give my password to a third party and I'll see if I can't sue. As someone in the IT field, I'd agree with the high rep users you mention and say that you aren't supposed to store a password. The user is trusting your system, giving their password to a third party is a violation of that trust more extreme than giving all of their information to someone. As a professional I would never do that.
    – jmoreno
    Commented Aug 10, 2011 at 3:15

He is probably testing you to see if you are a security risk. If you provide these details to him then you will probably be instantly dismissed. Take this to your immediate boss and pass the buck. Let your boss know that you will involve the relevant authorities if this arse comes anywhere near you again.

That's what bosses are paid for.

I have a vision of a piece of paper left in the back of a taxi cab that has a list of passwords, SSH keys and user names on it! Hhhmmm! Can see the newspaper headlines right now!


In response to the 2 comments below I guess you both have good points to make. There is no way of really finding out the truth and the fact the question was posted at all shows a little naiveté on the part of the poster as well as courage to face an adverse situation with potential career consequences where others would stick their head in the sand and run away.

My conclusion for what it's worth is that this is a thoroughly interesting debate that has probably got most readers wondering what they would do in this situation regardless of whether or not the auditor or the auditors policies are competent. Most people will face this kind of dilemma in some shape or form in their working lives and this really isn't the kind of responsibility that should be shoved onto one single persons shoulders. It's a business decision rather than an individuals decision as to how to deal with this.

  • 1
    I'm surprised this hasn't got higher votes. I just don't believe the auditor is "stupid". As others have said in comments, but not many as answers, this reeks of social engineering. And when the first thing the OP does is post on here and suggest he may fake the data, and then sends the link to the auditor, the guy must be laughing his ass off, and continuing to ask based on this. SURELY?!?!
    – ozz
    Commented Jul 29, 2011 at 8:08
  • 3
    Given that he's lost his company the OPs business as a result, it doesn't seem like a very good audit technique if that was the case. At least I'd have expected him to 'come clean' when it became obvious they were losing the business, and explain that it was part of the audit approach in use, rather than continuing to insist on it. I can understand if you bring in 'ethical hackers' you might expect a 'social engineering' approach such as this to be taken, but not for an audit (which is aimed at checking that all appropriate checks and procedures are in place)
    – Kris C
    Commented Aug 3, 2011 at 15:18
  • 2
    Given the further emails from the auditor, I no longer think this is true. the responders all need to get their facts right. I have been in this industry longer than anyone on that site – priceless
    – SLaks
    Commented Aug 3, 2011 at 19:00
  • Exactly, I'm glad someone mentioned it. Escalation to your manager/boss is first instance and mark the auditor behavior as suspicious and suggest the escalation to authorities is first step. I just can't believe this wasn't first answer. If the boss and boss of the boss wouldn't care, I'd just cc or bcc the authorities and the boss of the auditor's company. Commented Jul 24, 2020 at 17:28

Clearly there is a lot of good info here, but allow me to add my 2c, as someone who writes software which is sold worldwide by my employer to large enterprises primarily to assist people in complying with account management security policies and passing audits; for what that is worth.

First, this sounds very suspicious, as you (and others) have noted. Either the auditor is just following a procedure he doesn't understand (possible), or testing you for vulnerability so social engineering (unlikely after followup exchanges), or a fraud social engineering you (also possible), or just a generic idiot (probably most likely). As far as advice, I'd offer that you should speak to your management, and/or find a new auditing company, and/or report this one to the appropriate oversight agency.

As for notes, a couple things:

  • It is possible (under specific conditions) to provide the information he requested, if your system is set up to allow it. It is not, however, in any sense a "best practice" for security, nor would it be at all common.
  • Generally, audits are concerned with validating practices, not examining actual secure information. I'd be highly suspicious of anyone asking for actual plain-text passwords or certificates, rather than the methods used to ensure they are "good" and secured properly.

Hope that helps, even if it's mostly reiterating what other people have advised. Like you, I'm not going to name my company, in my case because I'm not speaking for them (personal account/opinions and all); apologies if that detracts from credibility, but so be it. Good luck.


This could and should be posted to the IT Security - Stack Exchange.

I'm not an expert in security auditing, but the first thing I've learned about security policy is "NEVER GIVE PASSWORDS AWAY". This guy maybe has been in this business for 10 years, but like Womble said "no, you have 5 minutes of experience repeated hundreds of times"

I've been working with banking IT people for some time, and when I saw you post, I showed it to them... They were laughing so hard. They told me that guy looks like a scam. They used to deal with this kind of thing for the security of the bank customer.

Asking for clear password, SSH keys, password logs, is clearly a serious professional misconduct. This guy is dangerous.

I hope everything is alright now, and that you don't have any problem with the fact they can have kept log of your previous transaction with them.


If you can provide any of the information (with the possible exception of the public keys) requested in points 1,2,4, and 5 you should expect to fail the audit.

Formally respond to points 1,2 and 5 saying you cannot comply as your security policy requires that you do not keep plain text passwords and that passwords are encrypted using a non reversible algorithm. To point 4, again, you cannot supply the private keys as it would violate your security policy.

As to point 3. If you have the data provide it. If you don't because you didn't have to collect it then say so and demonstrate how you are now (working towards) meeting the new requirement.


As oli said: the person in question is trying to get you to break the law (Data Protection/EU confidentiality directives)/internal regulations/PCI standards. Not only should you have to notify management (as you already did I think), but you can call the police as suggested.

If the person in question holds some kind of accreditation/certification, e.g. CISA (Certified Information Systems Auditor), or the UK equivalent of US CPA (a public accountant designation), you could also inform the accrediting organisations to investigate him for this. Not only is that person trying to get you to break the law, it's also extremely incompetent "auditing" and probably in contravention of every ethical audit standard by which accredited auditors must abide on pain of loss of accreditation.

Additionally, if the person in question is member of a larger company, forementioned auditing organisations often require some kind of QA department that oversees quality of audits and audit filing and investigates complaints. So you may also have a go at complaining to the audit company in question.


A security auditor for our servers has demanded the following within two weeks:


If we fail the security audit we loose 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?

It appears as though you have answered your own question. (See bolded text for hints.)

Only one solution comes to mind: get everyone to write down their last and current password and then immediately change it to a new one. If he's wanting to test password quality (and the quality of transitions from password to password, e.g. to make sure nobody uses rfvujn125 and then rfvujn126 as their next password,) that list of old passwords should be sufficient.

If that is not deemed acceptable, then I'd suspect the guy is a member of Anonymous/LulzSec... at which point you should ask him what his handle is and tell him to quit being such a scrub!

  • 22
    People shouldn't be asked to provide their own passwords to anyone. Commented Jul 24, 2011 at 2:45
  • Develop good password change functions, rather than record users current passwords and force a change. E.g., on the password change screen the user types inputs both old_pass & new_pass. Develop a series of automated checks; e.g., that no more than two characters in old_pass are in new_pass in the same location; or that in any order there no more than 4 characters are reused in any location. Furthermore, check that new_pass wouldn't work as any of the old pw. Yes, one could get away a series of unsecured passwords like rfvujn125 / jgwoei125 / rfvujn126, but that should be acceptable.
    – dr jimbob
    Commented Jul 25, 2011 at 17:24

I'm still studying and the first thing I learned when setting up servers is that if you make it possible to log plaintext passwords, you already endanger yourself for a giant breach. No password should be known except to the user that employs it.

If this guy is a serious auditor he shouldn't be asking you these things. To me he kind of sounds like a misfeasor. I'd check with the regulating organ because this guy sounds like a complete idiot.


Hold on, he believes you should use a symmetric encryption just to transmit the password, but then store them plaintext in your database, or provide a way to decrypt them. So basically, after all the anonymous attacks on databases, where they showed plain text user passwords, he STILL believes this is a good way of "securing" an environment.

He is a dinosaur stuck in the 1960s...

  • 10
    "He is a dinosaur stuck in the 90's" - I'd guess in the 70's, actually. 1870's to be precise. God bless Auguste Kerckhoffs. :) Commented Jul 27, 2011 at 13:10
  • 5
    90s? I believe unix used hashed & salted passwords in the 1970s... Commented Jul 27, 2011 at 16:50
  • 7
    I love the fact Lucas changed it to 1960s now :)
    – rickyduck
    Commented Aug 4, 2011 at 11:11
  • 1
    Did any computer (excepting BASIC tutorials for home micro) system ever have serious passwords and store them in plaintext?
    – XTL
    Commented Mar 20, 2012 at 13:54
  • maybe a very long time ago... can't point you to any tutorials. But this site is not really suited for home systems, I suggest you have a look at superuser.com. Why on earth would you store credit card details/passwords plain text anyway? Only poorly designed systems do. Commented Mar 20, 2012 at 13:59
  • A list of current usernames and plain-text passwords for all user accounts on all servers
    • Current usernames MAY be within scope of "we can release this" and should be within scope of "we can show you this, but you may not take it off-site".
    • Plain-text passwords should not exist for longer than it takes to one-way hash them and they should certainly never leave memory (not even to go across wires), so their existence in permanent storage is a no-no.
  • A list of all password changes for the past six months, again in plain-text
    • See "permanent storage is a no-no".
  • A list of "every file added to the server from remote devices" in the past six months
    • This may be to ensure that you log file transfers to/from payment-processing server(s), if you have the logs it should be OK to pass on. If you don't have teh logs, check what the relevant security policies say about logging that info.
  • The public and private keys of any SSH keys
    • Maybe an attempt to check that 'SSH keys must have a pass-phrase' is in the policy and followed. You do want pass-phrases on all private keys.
  • An email sent to him every time a user changes their password, containing the plain text password
    • This is most definitely a no-no.

I'd respond with something along the lines of my answers, backed up by PCI-compliance, SOX_compliance and internal security policy documents as needed.


This guys request reeks to high heaven, and I'd agree that any correspondence from here on out should be going through the CTO. Either he's trying to make you the fall guy for not being able to meet said request, for releasing confidential information, or is grossly incompetent. Hopefully your CTO/manager will do a double take on this guys request and positive action will be done, and if they're gung ho behind this guy's actions....well, good sys admins are always in demand on the classifieds, as ti sounds like it's time to start looking for some place out if that happens.


I would tell him that it takes time, effort and money to build the cracking infrastructure for the passwords, but because you use strong hashing like SHA256 or whatever, it might not be possible to provide the passwords within 2 weeks. On the top of that, I would tell that I contacted legal department to confirm if it is lawful to share this data with anybody. PCI DSS also a good idea to mention as you did. :)

My colleagues are shocked by reading this post.


I would be strongly tempted to give him a list of username/passwords/private keys for honeypot accounts then if he ever tests the logins for these accounts do him for unauthorised access to a computer system. Though, unfortunately this probably exposes you to at a minimum some kind of civil tort for making a fraudulent representation.


Simply decline revealing the information, stating that you can not pass on the passwords as you do not have access to them. Being an auditor myself, he must be representing some institution. Such institutions generally publish guidelines for such an audit. See if such a request conforms to those guidelines. You can even complain to such associations. Also make it clear to the auditor that in case of any wrongdoings the blame may come back to him (the auditor) as he has all the passwords.


I would say that there is no way for you to provide him with ANY of the information requested.

  • Usernames provide him with an insight into the accounts that have access to your systems, a security risk
  • Password history would provide an insight into password patterns used giving him a possible avenue of attack by guessing the next password in the chain
  • Files transferred to the system may contain confidential information that could be used in an attack against your systems, as well as giving them an insight into your file system structure
  • Public and private keys, what the hell would be the point in having them if you were to give them out to someone other than the intended user?
  • An email sent every time a user changes a password would give him up to date passwords for every user account.

This guy is pulling your plonker mate! You need to get in touch with either his manager or some other auditor in the company to confirm his outrageous demands. And move away ASAP.


Problem solved by now, but for the benefit of future readers ...

Considering that:

  • You seem to have spent more than an hour on this.

  • You've had to consult the company's legal counsel.

  • They're asking for a lot of work after altering your agreement.

  • You'll be out money and more time switching over.

You should explain that you'll need a lot of money up front and there's a four hour minimum.

Last few times I told someone that they suddenly weren't so needy.

You can still bill them for any loss incurred during switchover and for the time taken, since they changed your agreement. I'm not saying that they'll pay within two weeks, much as they thought you would comply within that time - they'll be one-sided, I have no doubt.

It will rattle them if your lawyer's office sends the collection notice. It should attract the attention of the owner of the auditor's company.

I would advise against any further dealings with them, just to further discuss the matter will entail a deposit for the work required. Then you can be paid for telling them off.

It's odd that you have an agreement in effect and then someone at the other end would go off the rails - if it's not a test of security or intelligence it's certainly a test of your patience.

You must log in to answer this question.