首先，不要投降。 他不仅是一个白痴，而且是一个不幸的错误。 事实上，发布这些信息将违反 PCI标准（这是我认为审计是因为它是一个支付处理器），以及其他所有标准和普通常识。 这也会让你的公司承担各种责任。

接下来我要做的就是给你的老板发一封电子邮件，说他需要得到公司法律顾问的帮助，才能决定公司将面临的法律风险。

最后一点是由你决定的，但是我会用这个信息联系VISA，并且让他的PCI审计员状态被拉下来。

作为已经通过普华永道审计程序与分类政府合同进行审计的人，我可以向你保证，这是完全不可能的，这个人是疯了。

当普华永道要检查我们的密码强度时：

• 询问我们的密码强度algorithm
• 根据我们的algorithm对testing单元进行检查，以检查他们是否会拒绝密码错误
• 当被要求看到我们的encryptionalgorithm，以确保它们不能被反转或不encryption（即使是彩虹表），甚至是被完全访问系统的每个方面的人
• 检查以前的密码是否被caching以确保它们不能被重新使用
• 当我们被要求获得许可（我们授予他们）试图使用非社会工程技术（如xss和非零日攻击等）进入networking和相关系统时，

如果我甚至暗示我可以向他们展示过去6个月内的用户密码是什么，他们会立即将我们的合同closures。

如果有可能提供这些要求，你会立即失败每一个值得的审计。

更新：你的回复邮件看起来不错。 比我会写的任何东西都要专业得多。

老实说，这听起来像是这个人（审计员）正在设置你。 如果你向他提供他所要求的信息，那么你已经向他certificate，你可以通过社交devise来放弃关键的内部信息。 失败。

我刚刚发现你在英国，这意味着他要求你做的是违反法律（实际上是“数据保护法”）。 我也在英国，为一家大型审计公司工作，了解这方面的法律和惯例。 我也是一个非常讨厌的工作，如果你喜欢为了它的乐趣，我会很乐意遏制这个家伙，让我知道你是否愿意帮忙。

你正在被社会devise。 要么是“testing你”，要么是黑客冒充审计员来获取一些非常有用的数据。

我非常担心OP缺乏道德问题解决能力，服务器故障界忽视这种公然违反道德操守的行为。

总之，我需要;

• 一种“假”六个月的密码更改方式，使其看起来有效
• 一种伪造入站文件传输六个月的方法

让我清楚两点：

1. 在正常业务过程中伪造数据是不合适的。
2. 你永远不应该泄露这种信息给任何人。 永远。

篡改logging不是你的工作。 这是你的工作，以确保任何必要的logging是可用的，准确的和安全的。

Server Fault的社区在处理“作业”问题时必须处理这些types的问题。 只有技术上的回应才能解决这些问题，或者忽视违反道德责任的行为。

看到这么多的高级代表用户在这里回答这个问题，没有提到这个问题的伦理含义让我感到悲伤。

我鼓励大家阅读SAGE系统pipe理员的道德准则 。

顺便说一句，你的安全审计是一个白痴，但这并不意味着你需要感到压力，在你的工作不道德。

编辑：你的更新是无价的。 低头，粉末干燥，不要拿（或给）任何木质的镍。

你不能给他想要的东西，而试图“伪造”它可能会回来咬你（可能在法律上）。 你或者需要对命令链进行申诉（尽pipe安全审计是非常愚蠢的 – 可能这个审计人员stream氓无耻 – 询问我想要通过SMB访问AS / 400的审计人员），或者得到地狱从这些苛刻的要求下面出来。

他们甚至没有很好的安全性 – 无论用什么方法来保护它们，所有明文密码的列表都是非常危险的事情，我敢打赌，这个家伙会希望他们用纯文本的方式发送电子邮件。 （我相信你已经知道了，我只需要发泄一点）。

对于狗屎和笑声，直接问他如何执行他的要求 – 承认你不知道如何，并希望利用他的经验。 一旦你走出去了，对他的“我在安全审计方面有十年以上的经验”的回应是“不，你有五百次经验重复数百次”。

如果审计员发现您现在已经修复的历史问题，那么审计员就不应该让您失望。 事实上，这是良好行为的证据。 考虑到这一点，我提出两点：

a）不要撒谎或制造东西。 b）阅读你的政策。

对我来说的关键是这一个：

所有[通用信用卡处理提供商]客户都必须符合我们的新安全政策

我敢打赌，这些政策中有一个声明说密码不能写下来，不能传递给用户以外的任何人。 如果有，那么将这些政策应用于他的请求。 我build议像这样处理它：

• 所有服务器上所有用户帐户的当前用户名和纯文本密码的列表

给他看一个用户名列表，但不要让他们被带走。 解释说明文密码是a）不可能的，因为它是单向的; b）违反政策，他正在审核你，所以你不会服从。

• 过去六个月的所有密码更改清单，再次以纯文本forms

解释说这不是历史上可用的。 给他一个最近的密码更改时间列表，以表明这是现在正在完成。 解释，如上所述，密码将不会提供。

• 过去六个月中“从远程设备添加到服务器的每个文件”的列表

解释什么是和没有被logging。 提供你能做的。 不要提供任何保密的东西，并解释为什么不。 询问你的日志logging是否需要改进。

• 任何SSH密钥的公钥和私钥

看看你的关键pipe理政策。 它应该说明私人钥匙不被允许离开他们的容器并且有严格的访问条件。 应用该策略，并且不允许访问。 公钥很高兴公开，可以共享。

• 每次用户更改密码时发送给他的电子邮件，其中包含明文密码

拒绝吧。 如果你有一个本地安全的日志服务器，让他看到这是logging在原地。

基本上，我很抱歉这样说，但是你必须和这个人打硬。 完全按照你的政策，不要偏离。 不撒谎。 如果他不让你做任何不在政策之内的事情，请向寄给他的公司的老人投诉。 收集这一切的纸质certificate，certificate你是合理的。 如果你违反了你的政策，那你就是在摆布。 如果你跟着他们的信，他最终会被解雇。

是的，审计员是一个白痴。 但是，如你所知，有时候白痴被置于权力的位置。 这是其中的一种情况。

他所要求的信息对系统当前的安全性没有任何影响。 向审计员解释您使用LDAP进行身份validation，并使用单向散列来存储密码。 对于密码哈希（可能需要几周（或几年））的蛮力脚本，您将无法提供密码。

同样，远程文件 – 我想听到，他认为你应该能够区分直接在服务器上创build的文件和SCP服务器上的文件。

正如@ womble所说，不要冒充任何东西。 那不会有好处。 要么把这个审计沟通起来，要罚款另一个经纪人，要么find一种方法来说服这个“专业人士”，他的奶酪已经从他的cookies中滑落。

让你的“安全审计员”指出任何这些有他的要求的文件中的任何文本，并在他努力想出一个借口，并最终借口自己永远不会再被听到。

WTF！ 对不起，但这是我唯一的反应。 我从来没有听说过需要明文密码的审计要求，更不用说在更改密码时给他们提供密码。

第一，请他向你展示你提供的要求。

第二，如果这是PCI（我们都假设，因为这是一个支付系统问题）去这里： https : //www.pcisecuritystandards.org/approved_companies_providers/qsa_companies.php并获得一个新的审计。

第三，按照他们上面所说的，联系你的pipe理层，让他们联系他正在合作的QSA公司。 然后马上得到另一个审计员。

审计人员对系统状态，标准，stream程等进行审计。他们不需要任何信息来提供对系统的访问。

如果您希望任何推荐的与审核员密切合作的审核员或备用colo，请联系我，我很乐意为您提供参考。

祝你好运！ 相信你的直觉，如果事情看起来不对，那可能就是。

他没有正当理由知道密码并可以访问私钥。 他所要求的将会使他有能力在任何时候冒充你的任何客户，并且尽可能多地吸收他想要的钱，而没有任何办法将其视为可能的欺诈交易。 这将是他应该审计你的安全威胁的types。

通知pipe理人员，审计员要求您提出安全政策，并且要求是非法的。 build议他们可能想要抛弃目前的审计公司，find合法的审计公司。 给警察打电话，让审计人员请求非法信息（在英国）。 然后打电话给PCI，然后打开审计员的要求。

这个要求类似于要求你随意杀人，然后交出尸体。 你会这样做吗？ 或者你打电话给警察，把他们打开？

回应一个官司 。 如果审计人员要求提供纯文本密码（现在就来吧，要破解或破解弱密码哈希并不困难），他们可能会对你的凭据撒谎。

只是关于你如何回应你的提示：

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.

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.

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. 祝你好运。

This could and should be pasted to the IT Security – Stack Exchange

I'm not an expert in security not auditing, but the first thing I've learned about security policie 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 seen 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, it's clearly a serious professionnal 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.

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, eg 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!

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

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…

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

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.

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.