Our security auditor is an idiot. How do I give him the information he wants?

Question

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.

Regards,
[me]

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

https://serverfault.com/questions/293217/

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

Excellent.

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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

Answer 6

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.

Answer 7

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

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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?

Answer 14

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.

Answer 15

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.

Or

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

Answer 16

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.

Answer 17

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!

Update

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.

Answer 18

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.

Answer 19

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.

Answer 20

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.

Answer 21

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.

Answer 22

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!

Answer 23

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.

Update

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

Answer 24

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

Answer 25

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.

Answer 26

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.

Answer 27

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.

Answer 28

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.

Answer 29

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.

Answer 30

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.