2448

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.

tom
  • 105
  • 2
Smudge
  • 24,039
  • 15
  • 57
  • 76
  • 512
    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 Jul 22 '11 at 22:54
  • 2
    @Scrivener Not that simple, the guy who owns the company I work for wants us to stay with this provider because they're cheap. I've already spoken to him about moving, even somewhere like PayPal would do as a stable ground while we figured something better out, but he says he only wants to use it as a last resort. I would never have personally chosen this provider but the decision was made before I arrived :( Also our programmer is unavailable so we'd have to bring someone new in – Smudge Jul 22 '11 at 23:00
  • 177
    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 Jul 22 '11 at 23:30
  • 5
    @A. Throwaway: A "last resort" is *exactly* what you use when you honestly fail this so-called "audit", no? Explain to the owner that you will simply fail this audit, and will have to prepare to move. – Teddy Jul 22 '11 at 23:37
  • 160
    He must be testing you to see if you're really that stupid. Right? I hope so... – Joe Phillips Jul 23 '11 at 00:05
  • 59
    I find it incredibly suspicious that everything he asked for is either designed to be impossible or somewhere on the security scale between `telnet` and a Post-It with a password stuck to the monitor. – Bacon Bits Jul 23 '11 at 00:49
  • 209
    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... – Bart Silverstrim Jul 23 '11 at 00:56
  • 11
    @A. Throwaway: I'm so glad people like you put up the effort to question requests. It reassures me that logical reasoning will prevail! – surfasb Jul 23 '11 at 01:51
  • 9
    Rant over: Please, please let us know how this pans out. I, along with the other 20 people who have favourited this question, are intrigued. – Mark Henderson Jul 23 '11 at 02:23
  • 11
    I'd like to know which payment processor is sending you this auditor so that I can avoid them in future projects. – JasonTrue Jul 23 '11 at 04:02
  • 19
    DUh. send him the encrypted passwords. Just tell him all your users follow the password policy very, very carefully, and pick random passwords :) – Brian Jul 23 '11 at 05:36
  • 15
    As @bacon bits hints at, I wonder if he's intentionally being obtuse just to see how you handle it, and the way you fail this audit is by *not* pointing at him and laughing until you pass out. In all seriousness, I suggest telling him that he can either revise his request to something sensible or get lost. Either way at that point you either past his first 'test' or you 'fire' a dangerous lunatic. I'm all about the win-win. – Rob Moir Jul 23 '11 at 07:48
  • 11
    As some have said, passwords in plain text = stupid. Emailing ANYONE with plain text passwords = stupid. Sending them private keys!? Correct me if I'm wrong, but private keys should remain JUST THAT!? – Relequestual Jul 23 '11 at 10:22
  • 14
    Please do not ever give everyone your SSH private key(s). – middus Jul 23 '11 at 11:19
  • 13
    It's fine to give someone your SSH private key; just stick a random string the length of *War and Peace* on as the passphrase first. – womble Jul 23 '11 at 11:45
  • 71
    This guy is dangerous and should be run out of the industry. Please name and shame him so nobody else ends up in this situation. Tell him that it is impossible because it SHOULD be impossible. Plain text passwords shouldn't exist outside grey matter. SSH private keys belong to the user not to the server. Any firm that can satisfy his requests is insecure. Any firm that fails his audit is secure. – Rincewind42 Jul 23 '11 at 12:10
  • 56
    If your story is true, I support naming and shaming this individual and the company he works for. – Sebastiano Pilla Jul 23 '11 at 12:17
  • 14
    Others have chimed in with much more intelligent comments and answers then I'm likely to provide, but I might suggest that you abandon your attempt at anonimity and show your boss this post so he can see for himself what real, working IT professionals think of the auditor's requests. You've gotten some very good answers here from people who are the best in the profession. – joeqwerty Jul 23 '11 at 12:26
  • 18
    In addition, each of the things the auditor is asking for is a security breach in and of itself. You shouldn't disclose the information he's requesting to anyone and I'm at a loss to understand any technical or legal reason for his wanting that information. You don't know this guy from Jack Black, why would you ever provide this information to him? Providing this information to him puts your entire organization at risk. I'm no legal or security expert but the first thing I would do would be to convince my boss that he needs to get a lawyer with compliance experience involved in this. – joeqwerty Jul 23 '11 at 12:33
  • 5
    You have a run on sentence. Otherwise, it's pretty much what I'd write. "I strongly suggest you review your audit requirements, there is currently no way for us to pass this audit while remaining in compliance of PCI and the Data Protection act." You should have an "as" after the first comma. Also, BCC your supervisor. I think they'll find his request.. interesting. – wjl Jul 23 '11 at 13:45
  • 5
    Nitpicking here, but "strong encryption" doesn't have to be a one-way hash. It could be reversible. That doesn't make his request any less ludicrous. – troelskn Jul 23 '11 at 13:50
  • 2
    If you really want to look water-tight, fix the misused comma in the last sentence of your draft. – Lightness Races in Orbit Jul 23 '11 at 14:15
  • 5
    After being asked for only one of those things I would just laugh in the face of the guy. *Private* SSH keys?! – Hubert Kario Jul 23 '11 at 16:50
  • 35
    You need to escalate up the chain, both yours, and his (payment provider). My guess is either black hat, or incredibly dumb. Escalate on the basis of security breach -- if we ever tried to give this to anyone, it would be an automatic security breach. – Jon Watte Jul 23 '11 at 16:51
  • 4
    Will you please stop spelling 'lose' incorrectly? – Mark Snidovich Jul 23 '11 at 18:12
  • 9
    Don't e-mail him anymore. Even to send that last e-mail you've edited into your question. The guy is bonkers and you should only communicate with him, at this point, if you are *specifically directed to* by your boss. – Shaggy Frog Jul 23 '11 at 18:19
  • 2
    there is no reason for the auditor to ever have copies of private keys, they are just that, private not distributed data. In fact, if I was the auditor someone gave me private ssh keys as part of the audit I would fail them on it if only I could find the right check box to check on the form. For weak password checking, the best usually done is let jacktheripper run with a nice dictionary on the database and attempt to crack. |Reporting a failure for each one, however one would expect validation limits when password is set enyway. – ewanm89 Jul 23 '11 at 19:54
  • 8
    Would you be able to post the security firm's name? I think this transcends issues of ethicality on posting firms/individual names on the big scary 'Internet' - This is a direct and immediate danger to any firm whom he 'audits', can you supply this information in the interest of protecting the innocent? – zetavolt Jul 24 '11 at 00:37
  • Are you quite sure this isn't a very *clever* auditor trying to see if your system is either insecure enough or you are stupid enough to give him this information? – crasic Jul 24 '11 at 04:59
  • @crasic, I think the OP covered that one in his first update. – womble Jul 24 '11 at 05:18
  • 325
    Any sufficiently advanced incompetence is indistinguishable from malice – Jeremy French Jul 24 '11 at 10:11
  • @geteipordietryin I will do once we've finished moving over to PayPal, they're a very small local company (<100 clients) so I'd guess they use Google Alerts etc. and could easily find this post if I named them – Smudge Jul 24 '11 at 10:43
  • 7
    On the topic of how to respond to the auditor, you might want to ask on [security.se], where there are plenty of people with PCI experience. – Gilles 'SO- stop being evil' Jul 24 '11 at 12:38
  • You may also be personally liable for some breaches of EU Data Protection legislation. I can't find a definitive reference at the moment, but I was clearly explained to me as an employee a few years ago. I found a summary at http://www.out-law.com/page-413 - search for "Employees may also incur criminal liability" – edoloughlin Jul 24 '11 at 16:17
  • Have a look here http://www.symantec.com/connect/articles/social-engineering-fundamentals-part-i-hacker-tactics sounds like that story. – Jacob Jul 24 '11 at 16:50
  • 24
    A throwaway name with nearly 500 rep and 3 gold badges. :P – Reid Jul 24 '11 at 21:23
  • 1
    That response is really great, firm but professional. So many people would have been craven or sarcastic! Please keep that tone for the body of the email, though you may want to follow up with some specific offers of what you can show him so in the unlikley event he's serious about this idiocy but willing to see reason, you still come off as helpful. – Jack V. Jul 25 '11 at 08:55
  • 1
    @Reid Oh no, what a waste of the digitals! All those tubes! – Kzqai Jul 25 '11 at 16:43
  • 11
    Of all the ludicrous parts of his request, giving your private SSH key is the worst. That's like "please give me the ability to sign your name and fake your fingerprints." He is either crazy, hacking you, or a moron. Giving that up would be worse for you than getting fired for not doing it; at least you won't be in the news when the company goes down in flames. – Nathan Long Jul 25 '11 at 17:39
  • 6
    Wow...I'm right out of school after studying Computer Science. I don't even dabble with security and I can tell you this looks shady. – MGZero Jul 25 '11 at 20:21
  • 40
    For the benefit of humanity, PLEASE tell us his name and what company he works for. They absolutely MUST be publicly exposed. – iconoclast Jul 26 '11 at 03:14
  • 1
    Regardless of whether you follow joekwerty's advice and making your identity known, it couldn't hurt to show your boss this post and the dramatic response. – Lisa Jul 26 '11 at 06:35
  • Any updates? It's been 3 days. – Mircea Chirea Jul 26 '11 at 19:00
  • I would give you 1337 medals for this.. haha, hilarious. – pauska Jul 26 '11 at 19:28
  • 6
    Well done, A. Throwaway. I applaud your persistence. My suggestion now would be to create a regular serverfault account for yourself and ask the serverfault admins to merge it with this one. – joeqwerty Jul 26 '11 at 19:29
  • 7
    Libel. If it's written it's libel, as I recall. Not liable. Or slander. – Bart Silverstrim Jul 26 '11 at 19:33
  • 7
    @Bart - It's only Libel if it's not true (at least in the US, and I believe under English law). If the lawyers agree I believe it would be a public service to name-and-shame this auditor/audit company. – voretaq7 Jul 26 '11 at 19:36
  • 18
    Posting his e-mail address is probably a bad idea. You're aware people are not happy with him and providing explicit means to contact/harass him is ethically dubious and legally questionable at best. His name and company name; that would be highly relevant (note you called him a *idiot*, best to separate opinion from fact if you're going to post those sorts of details). IANAL, this is not a legal opinion. – Chris S Jul 26 '11 at 19:39
  • 11
    The UK has some pretty strong libel laws so I'd be wary of that before posting the name of the person/company. – ErnieTheGeek Jul 26 '11 at 19:39
  • 1
    I want to thank you for having the balls to stand up to this guy! – funkymushroom Jul 26 '11 at 19:50
  • @voretaq7: True, I was just referring to the entire threat made in the messages that it would be liable(sic) if OP published information. – Bart Silverstrim Jul 26 '11 at 19:58
  • 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. --> Yup. The businesses' data isn't worth anything if it gets in the hands of competitors or criminals. LMAO @ whole stack of email. – Mircea Chirea Jul 26 '11 at 20:03
  • Glad to see a good ending, and thanks for keeping us updated in the meantime. – lccarrasco Jul 26 '11 at 20:12
  • Upvoted for an even 400... and there is no way that guy can be a real security auditor, unless they let you do that when you have an iq under 50. – MirroredFate Jul 26 '11 at 20:16
  • 3
    Sounds like you've done all the right things. To this, however: `if they were doing this internally I think the only responsible thing to do would be to inform our customers...` I'm not sure about the UK, but in the US, when a vendor knows there has been a breach, we are required to inform the customers. As I understand the UK laws are tighter than the US, this might be good insurance. – Adrien Jul 26 '11 at 20:37
  • 4
    I genuinely smiled when I read that pci was not installed ;) anyhow if you want to keep this we can merge your two accounts together? (we can see your dupes, normally we'd merge them but these were... Extenuating circumstances) – Mark Henderson Jul 26 '11 at 20:51
  • 2
    @Adrien Yeah restrictions are very tight in the UK, but my legal guy has told me we're currently taking the right steps by informing PCI SSC but we don't have to do anything until they get back to us and say yes or no. – Smudge Jul 26 '11 at 21:05
  • 12
    For the benefit of MANKIND, PLEASE reveal that GUY. – prusswan Jul 26 '11 at 21:21
  • @sam I think you should just accept Chopper's answer for suggesting a curbstomping and call it a day. – MDMarra Jul 26 '11 at 21:22
  • 4
    @MarkM curbstomping is so abrupt, I'd rather do something longer term. He wants us to email him when we change a password. Well what if I set up a script to email him 5000 random passwords a day, we're sticking as closely as possible to his guidelines =) – Smudge Jul 26 '11 at 21:32
  • 1
    @Chris S - posting his name, phone, company, email, and company address is all quite legit so long as that information is already available on the company's website – warren Jul 26 '11 at 21:59
  • 44
    This is one of the most entertaining posts I've ever read on the Stack Exchange network – Earlz Jul 26 '11 at 22:16
  • 1
    Glad you basically have it sorted. I looked at PCI compliance when implementing a payment system one time and decided it was too risky. So we went with a payments gateway who are PCI compliant and then we didn't have to worry about the security aspect since the payments were not taken by our website... similar to the way paypal works. Much easier! – hookenz Jul 26 '11 at 22:18
  • 12
    Also, congratulations on breaking quite a few SF records. I'm fairly sure this question has the most upvotes, the most views, the most favourites, and its answers have the highest votes of any other question on server fault. It also sat on the top of the Stack Exchange hot questions for three days straight (now dropped the 2nd place, awww). And all in 4 days! – Mark Henderson Jul 26 '11 at 23:06
  • 2
    Wow, I LOLed so hard. Congrats on the teasing title (and also your handling of the situation :) – mousio Jul 27 '11 at 01:20
  • Not sure if there is something like the Better Business Bureau in the UK but if there is that guy needs a serious reporting. That will be a bit more official and probably more acceptable to your legal guy than ratting him out on an Internet Q&A site. – squillman Jul 27 '11 at 01:27
  • side question: does PCI SSC actually put up a list of known offender(s)? – prusswan Jul 27 '11 at 02:34
  • 1
    @prusswan Probably just a revocation of.. well.. any accreditation that they can. – Shane Madden Jul 27 '11 at 02:56
  • I signed up to ServerFault just so I could favourite this question. I'm glad to see reason has prevailed. I've suffered the misdirected pedantry and bullish facade from "expert" consultants on various software projects and I'm glad to see you weathered the waves of blathering in the right way. – Jodrell Jul 27 '11 at 08:49
  • 46
    A quote from LulzSec themselves: "What’s worse is that every bit of data we took wasn’t encrypted. Sony stored over 1,000,000 passwords of its customers in plaintext, which means it’s just a matter of taking it. This is disgraceful and insecure: they were asking for it." – Chris Burt-Brown Jul 27 '11 at 10:38
  • Remember, its only liable if its NOT TRUE! – Andy Jul 27 '11 at 13:24
  • 1
    Looks like you have a problem with these kinds of people: http://serverfault.com/questions/268542/hardware-firewall-vs-software-firewall-ip-tables-rhel – CesarB Jul 27 '11 at 13:41
  • 7
    Note that in the UK, although truth is an absolute defence to libel, the burden is on the *defendant* to prove that it is true. Almost certainly more trouble than it's worth. – Daniel Roseman Jul 27 '11 at 14:12
  • 3
    Even though you can't reveal the guy's name or the company he works for, I hope you can update on whether he loses his auditing status. – inTide Jul 27 '11 at 18:47
  • 2
    @al I gave him my bank details, he says he's going to send me a billion $ but there's a small processing fee I have to pay, seems reasonable and there doesn't seem to be anything against it in the PCI guidelines =) – Smudge Jul 27 '11 at 19:30
  • 3
    @inTide I'll try and keep in touch with the situation, not sure how long PCI will take to investigate, and even if they'll get back to me but if I hear anything I'll update the thread – Smudge Jul 27 '11 at 19:31
  • @CesarB Yeah I seem to attract idiots (Not sure if that should tell me something ha). That was a seperate company and just a webserver, if I remember correctly PCI reccomends use of a seperate device as a firewall, and wherever budget/requirement permit I like to use a separate firewall device (and was with these servers) – Smudge Jul 27 '11 at 19:34
  • 37
    `I'm going to assume you do not have PCI installed on your servers` Sounds like he's right about something. – theycallmemorty Jul 27 '11 at 21:00
  • 5
    lol at you accidentally telling him that he's an idiot. :) – Mateen Ulhaq Jul 28 '11 at 06:33
  • 8
    if I were your boss, I'd give you a raise – tkit Jul 28 '11 at 07:26
  • Any chance it's a trick. Sounds to me like a situation where if you do give him what he wants, you fail the audit. –  Jul 25 '11 at 05:06
  • 5
    You clearly did the right thing - posting this to well known Q&A site. We can only hope that the auditor and/or his peers see this. Now you need to get a second opinion - check the set of requirements with another auditor firm. – Peter Knego Jul 23 '11 at 12:13
  • 4
    this is similar to how mtgox got hacked. that gave a security consultant a bunch of hashed passwords and he lost them and someone was able to break the passwords and compromise the system. giving someone plaintext passwords and SSH private keys is incredibly irresponsible. – benmmurphy Jul 23 '11 at 10:06
  • 2
    The people on the I.T. Security Stack Exchange really need to see this (maybe most of them are users here too). Good job calling B.S. on this "expert." – Bratch Jul 28 '11 at 15:26
  • 2
    @pootzko If I was my boss I'd give me a raise =) Wait does that work? – Smudge Jul 28 '11 at 16:31
  • 1
    I'm not even in security and I know all the things he's asking for are bad ideas. What a dumbass. – kekekela Jul 29 '11 at 19:11
  • I'm interested how revealing a *true* experience with a provider is any different than providing a review of a business, offline OR online. You probably shouldn't reveal his name, but I think you are absolutely in the clear to post his companies name and would be a little irresponsible not to - he is dangerously deceiving people that could have serious consequences, I'd hope that you would reveal the identity of a serial killer regardless of legal consequences, I don't know why the ethical principle would be different regarding incompetence and potentially millions of dollars of loss. – zetavolt Jul 29 '11 at 23:16
  • 2
    @Sam Any chance of an update? This novel could do with an ending if you have one – KCD Sep 26 '11 at 21:50
  • 24
    @KCD Alas no, I have tried to stay in contact with the company and keep up with what's going on, but understandably they don't really seem to want me around any more now we've moved away. I do know they have got rid of the auditor, they also contacted the few customers using this service to make sure they didn't follow any of his advise, and have offered to pay any costs associated with this whole saga (There weren't any, apart from the few things I broke getting frustrated). I don't think they intended any of this to happen, they just weren't paying attention to their customers – Smudge Sep 27 '11 at 08:41
  • 7
    One of the most awesome question on the whole StackExchange network :) – haylem Feb 29 '12 at 17:40
  • 1
    Reading this has made me so mad! I can't stand when people are so blind and they refuse to listen and do their research. I wish you would expose the company (maybe the BBB?) .. I can understand that even frivolous legal trouble can be costly though I'm sure the First Amendment would protect you assuming none of the above is forged. I find it very interesting that PCI talks about **strong cryptography** for password protection as opposed to digest. – Explosion Pills May 02 '12 at 14:39
  • 3
    @ExplosionPills - the first amendment only applies to America, and the op is from the UK. The UK has *very* strong Libel laws. In fact, America is one of the only countries in the world to protect free speach; it's something the vast majority of the rest of the world (developed and undeveloped) doesn't have. – Mark Henderson May 22 '12 at 09:07
  • 1
    I just hope his boss reads this thread... – frnhr Aug 15 '12 at 18:23
  • 3
    @MarkHenderson Woah there! Freedom of speech is e.g. among the [Fundamental Rights in the German Constitution](http://www.iuscomp.org/gla/statutes/GG.htm#5). It's just appreciated not being a dick about it, e.g. by asking you to respect "the right to personal honor". And even in the US (which is not the _entire_ America FYI) you _do_ think twice before using your freedom of speech to state something stupid like "you don't even have PCI installed". Or [Threatening the President](http://en.wikipedia.org/wiki/Threatening_the_President_of_the_United_States). – Tobias Kienzler Oct 11 '12 at 06:56
  • @Cek His boss will probably just ask him not to waste time reading such "misinformed crap" and obtain more passwords :-P – Tobias Kienzler Oct 11 '12 at 06:57
  • 2
    @sam Any updates on the investiation? You should accept an answer btw... – Tobias Kienzler Oct 11 '12 at 07:01
  • 2
    I love when people who don't know jack think that because they've been "doing" something a long time that it means they've been doing it well or correctly. Time can very rarely act as a substitute for intelligence as this (hopefully ex-) auditor proves. – ColinM Jan 17 '13 at 19:35
  • 2
    This just screams "Dunning-Kruger"... – Jürgen A. Erhard Jan 29 '13 at 09:23
  • 3
    @sam Did you ever heard back something regarding the investigation? If so, could you share it? – gxx Jan 08 '16 at 08:15
  • 11
    What happened after you reported him to PCI? Please update...! Don't leave a cliffhanger! – Hendy Irawan Aug 28 '16 at 06:41
  • 3
    I like how he thinks libel is spelt "liable". – Lightness Races in Orbit Aug 31 '16 at 22:24
  • 1
    Send him a link to "password hashing". – noɥʇʎԀʎzɐɹƆ Sep 05 '16 at 14:35
  • 1
    Curious as to how their company got PCI compliant to begin with. Wow. – Rob Sep 05 '16 at 20:32
  • "I have been in this industry longer than anyone on that site, getting a list of user account passwords is incredibly basic," Unless his first computer used tubes, I can guarantee that he's wrong. I think he was testing you, since keeping the passwords is expressly forbidden. –  Sep 06 '16 at 18:10
  • This sounds exactly like a particular manager at City of Virginia Beach. Except that he can't spell "Linux" so it can't be him. – Skatterbrainz Sep 10 '16 at 23:34
  • Seriously: If your company has internal legal counsel, schedule a meeting with them asap. Find out your options w/rt to your company policies and what your options are. If they are bad, start updating your resume. – Skatterbrainz Sep 10 '16 at 23:36
  • 1
    Hoping this is some kind of social engineering test and if you say now you pass? – RoguePlanetoid Sep 12 '16 at 11:13
  • @Wedge "Fire yourself"? Er, what did OP do wrong? – Kyle Strand Nov 21 '16 at 21:49
  • One of the major decision anyone will face soon is to remove any payment option other than Bitcoin. Your customers will evolve to pay using Bitcoin instead PayPal etc. – opengrid Dec 28 '16 at 15:26
  • Wow. Looking at his 'auditing demands', one thing came to mind - he's basically asking for all of your customer's data! That's one big privacy breach... and I think your decision to move to another payment processing service was the right move. – George Erhard Feb 28 '17 at 17:36
  • 2
    To be clear, "I would also like to suggest that any attempt to reveal me, or [company name] will be considered liable and appropriate legal action will be taken" is an absolute indication that the "auditor" knows he's doing something that would get him and his company in a lot of trouble. Given his demands I would suspect that he's actually either an attacker attempting to social engineer you, or he's a legit employee that's conducting unapproved information gathering. Have your legal council directly contact their legal council with the information, describe it as "responsible disclosure" ;) – Kaithar Mar 12 '17 at 21:54
  • 26
    `I'd actually forgotten I'd called him an idiot in the title` — I wish I could give another upvote just for that mishap. – Mark K Cowan Mar 12 '17 at 23:50
  • 4
    Was the name of the company ever revealed? – Darren H Mar 14 '17 at 11:22
  • 1
    I laughed so hard that I snorted milk out of my nose ! – Mawg says reinstate Monica Mar 17 '17 at 09:19
  • 2
    And then I scrolled back to the top of the page to check if this was posted on the first of April – Mawg says reinstate Monica Mar 17 '17 at 09:20
  • 4
    I've observed that its quite common for people who or either incompetent or dishonest (or both) to assert how long they've been in their profession if you disagree with them. In fact, I not too long ago had this experience with a plumber. – orodbhen Jun 27 '17 at 14:22
  • 1
    @orodbhen Incompetent people usually lack the skills needed to see that they are incompetente to begin with. – T. Sar Oct 27 '17 at 11:12
  • I love how you gave him the link to this question where you called him an idiot in a 24px font. That was amazingly (if unintentionally) savage. – Hankrecords Oct 27 '17 at 14:14
  • 2
    At least the individual knew the different between libel and slander. Of course as pointed out, factual information isn't libel, and cannot be libel since libel is is publishing false information (and you must know it's false when it's published at least in the US). – Ramhound Oct 27 '17 at 14:17
  • 3
    OP you should suggest that the auditor sign up and write his own answer if he thinks we don't know what we're talking about. I would LOVE to see that –  Nov 03 '17 at 19:16
  • 7
    Any more updates? I think the community would enjoy hearing how PCI responded. – Dessa Simpson Sep 07 '18 at 15:41
  • 4
    Please MD5-hash the company name and "accidentally" leak it somewhere :) For "security" purposes, only the first name (preferably less than 8 characters). – Eric Wu Oct 18 '18 at 21:04
  • I'd be curious how you actually got involved with this company. I doubt he was an idiot, but he also was not an actual security auditor. It sounds like you almost fell prey to a bogus criminal organisation. – user1751825 Aug 23 '19 at 02:39
  • 1
    Well at least now I know he doesn't work for Paypal. Thank God. – cowlinator Feb 05 '20 at 20:07
  • Maybe the company's on another company, or another country payroll and is using this technique to get into their preys' systems. Honestly, this is too obvious to be stupidity. There could really be the will to collect sensitive data behind such requests. – FarO Mar 14 '20 at 10:58
  • Finally I found the ultimate question on all stack exchange sites!! XDD – Sven Jun 23 '20 at 16:46
  • He keeps emphasizing how long he has been in the industry. He doesn't seem to be emphasizing how up to date his knowledge is. Perhaps it isn't very up to date? Perhaps public key cryptography wasn't in much use back in the day? – Szczepan Hołyszewski Sep 17 '20 at 13:57
  • The twist is: He really has been given plaintext password by hundreds of companies and he's also the best at social engineering on the planet earth. – iPherian Nov 09 '20 at 08:16
  • "An email sent to him every time a user changes their password, containing the plain text password" So basically, it's a demand to publish in the NY Times all your passwords in plain text. Very secure minded this auditor is as Yoda would comment. – boardrider Dec 24 '20 at 19:10
  • This is my favoruite post of the month, and the month has only just started. :)) – Dark Star1 Dec 07 '21 at 10:13
  • Wow! What an extremely entertaining story! Too bad you had to live though that! I would hire the auditor as a consultat to do the incredibly easy tasks he wanted you to do. Since it's so easy, he'd probably not have a problem with a fixed rate. :-) – Ted Lyngmo Mar 05 '22 at 16:31

31 Answers31

1308

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.

yoozer8
  • 322
  • 2
  • 12
Zypher
  • 36,995
  • 5
  • 52
  • 95
  • 312
    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 Jul 22 '11 at 23:29
  • 104
    "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 Jul 23 '11 at 00:53
  • 150
    This is all assuming that this fellow is actually a legitimate auditor... he sounds awfully suspicious to me. – Reid Jul 23 '11 at 01:30
  • 36
    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 Jul 23 '11 at 03:09
  • 27
    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 Jul 23 '11 at 05:17
  • 1
    Thanks for the update - The response you received sais more about the auditor than anyone on here – jamesc Jul 29 '11 at 02:12
  • Yeah, he has GOT to push back on this hard. – figtrap May 19 '17 at 20:35
  • 1
    @Wesley and all the other one are right. Who is so fool to provide all information like users, password in plain text, credit card information and so on so forth. Why we use crypto salt and more stuff to protect data? To grant access in plain text to someone? Something or someone is wrong. And i suppose that who is wrong is this "audit". He/She has to make a long long long travel do Sahara Desert :D LOL – makemoney2010 Sep 19 '17 at 15:44
  • @TomTom The plain text passwords would be impossible, but the SSH Keys are not. It's lucky the OP wised up before providing any of this information. – user1751825 Aug 23 '19 at 02:41
  • As a user of websites, I would be very upset if a company could provide my plaintext password to anybody. – cowlinator Feb 05 '20 at 20:13
904

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.

Kalle Richter
  • 259
  • 6
  • 17
Mark Henderson
  • 68,316
  • 31
  • 175
  • 255
  • 117
    +1. Looks like sensible quesstions that should NOT BE ANSWERABLE. If you can answer them you have a stupid security issue at hand. – TomTom Jul 23 '11 at 05: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 – Hubert Kario Jul 23 '11 at 16:45
  • 7
    @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. – Mark Henderson Jul 23 '11 at 21:59
  • @Mark: I know the algorithms are not available, the settings are important then. If you weren't integrated to AD or Kerberos then it would look OK. – Hubert Kario Jul 24 '11 at 18:29
  • You're not supposed to let a user use a previous password (i.e. if they change their password back to the old one again)? – Explosion Pills Jul 25 '11 at 23:20
  • 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. – Mark Henderson Jul 25 '11 at 23:39
  • Yep, you can't use your last 10 in my company. – cularis Jul 27 '11 at 13:05
  • Oddly, when I saw the 'user passwords over the last 6 months', my mind went to the password history that prevents re-use. Typically that history is count-based though, not time-period based, but other than that it would serve to address the need. – Slartibartfast Jul 28 '11 at 00:04
  • While I don't question this statement it's true "As someone who has been through the audit procedure with Price Waterhouse Coopers for a classified government contract" I think you'll be better walking away from the Appeal to authorithy falacy "http://www.nizkor.org/features/fallacies/appeal-to-authority.html" and focus more in the really good points and ideas you explained in your answer. – MexicanHacker Jul 28 '11 at 16:10
  • The company's correspondence with the OP has all the hallmarks of an actual scam. I'd consider reporting it to law enforcement. – thomasrutter Jul 29 '11 at 00:37
  • 3
    @Slartibartfast: you don't need to have the passwords in plain text to prevent reuse of password in the last six month, all you need is a database table that stores the hash, the salt (if applicable), and the date of password. – Lie Ryan Jul 31 '11 at 22:15
  • @Lie Ryan: Not if you also have to protect against using similar passwords, e.g. mypassword-08-2011 as compared to mypassword-07-2011 last month. (in anticipation of a specific response, yes, you could brute-force some comparisons, but that becomes computationally infeasible for a defender who has to evaluate a password choice in real-time, whereas the attacker has time on their hands) – Slartibartfast Aug 02 '11 at 04:48
  • 12
    @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 Aug 02 '11 at 14:15
  • Sorry, I'm confused about something -- you say you cached recent passwords, but if there'd been a hint of being able to show recent passwords, you'd have lost the contract. Did you mean that you cache the hashes of recent passwords (and then, presumably, compare against those)? – Nic Mar 10 '17 at 15:34
  • @QPaysTaxes this project in question was about 6 or 7 years ago, so I don't remember the exact details, but yes - it would have been the salted hashes of the passwords that were stored, not the passwords themselves. Wow actually I just realised it's been 6 years since I _wrote_ this answer, so that project was probably more like 8 or 9 years ago. – Mark Henderson Mar 10 '17 at 16:10
  • Funny idea: maybe whoever at your company ordered the audit checked the "social engineering attacks" checkbox by accident, and this guy was testing YOU (and you passed in spades)? – Szczepan Hołyszewski Sep 17 '20 at 13:49
492

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.

Peter Mortensen
  • 2,319
  • 5
  • 23
  • 24
anastrophe
  • 5,388
  • 2
  • 15
  • 16
  • 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 Jul 22 '11 at 23:42
  • 188
    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 – Joe Phillips Jul 23 '11 at 00: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 Jul 23 '11 at 02:59
  • 3
    @ Joe: Given the overkill amount of insanely insecure information he's asking for, i'd putting my money on very dumb – Sirex Jul 23 '11 at 06:15
  • 50
    Dumb question: is “setting up” acceptable in this situation? Common logic tells me an audit process should not be made of “tricks”. – Agos Jul 23 '11 at 21:04
  • 2
    @Agos: from a moral standpoint it may be problematic, but from a practial standpoint, facts, however they are discovered, tend to have a higher weight for the people who enforced the audit. – keppla Jul 25 '11 at 07:31
  • But just as a police interrogation must respect certain rules, I would expect that violations that are *asked for* in the process are not considerable “real” violations. – Agos Jul 25 '11 at 14:01
  • 19
    @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 " asked me to call you and get your login credentials so that I can ." 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 or and report the interchange. – Toby Jul 28 '11 at 12:04
  • 3
    ...and as always the old adage turned out true: “do not ascribe to malice that which can be adequately explained by incompetence” ;) – Agos Jul 29 '11 at 08:17
  • 1
    Besides, you shouldn't even have access to most of the information (i.e. pain text passwords O_o) he's asking for. – juanmf Feb 08 '17 at 16:04
  • 1
    @Toby These sorts of faux social engineering attacks are common, but they can only be done *with permission and knowledge of people within the company*. What the OP describes seems to be involvement in a normal audit process where they know the company they are dealing with. You also wouldn't expect such a test to be this brazen and outrageous, asking for plain text passwords and demanding e-mails be sent to them every time a password changes. If the latter actually happened, they'd probably expose themselves to liability asking for it. No, a test would be more sensible and routine sounding. – jpmc26 Oct 02 '18 at 20:39
  • 1
    This could be the case. He could have been testing you. Nobody with even a rudimentary understanding of IT security could genuinely believe that passwords are stored using reversible encryption. Also the "only applies to consumers" bit also seems like a test. You've provided the correct answers to him, and despite his responses, your answers were likely exactly what he was hoping to receive. – user1751825 Aug 23 '19 at 02:29
369

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.

Chopper3
  • 100,240
  • 9
  • 106
  • 238
  • 1
    This has nothing to do with the data protection act, which is purely related to personally identifiable information. From the sound of it, this is a PCI audit. – Jimmy Jul 23 '11 at 14:06
  • 33
    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.") – Stephen Veiss Jul 23 '11 at 15:18
  • 1
    Assuming there's any personal information on those servers, yes. But it's far from clear there is. Are you suggesting it would be ok if he passed over the plain text passwords of all servers not holding personal data? The main issues are that this is a) against policy, and b) against PCI. You don't need to bring distractions into it. – Jimmy Jul 23 '11 at 16:17
  • 1
    To be fair, though, (as I can't edit the answer above) I'd just like to add that your answer is correct. If the server holds personal data, anything that weakens that server or the system accessing it is technically in scope of principle 7. – Jimmy Jul 23 '11 at 16:33
  • 5
    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. – Stephen Veiss Jul 23 '11 at 18:25
  • 4
    @Jimmy why would a password not be personal data? – robertc Jul 24 '11 at 20:45
  • 10
    @Richard, you do know it was a metaphor right? – Chopper3 Jul 28 '11 at 09:34
  • 9
    @Chopper3 Yes, I still think that it's inappropriate. Plus, I'm countering AviD. – Richard Gadsden Jul 28 '11 at 09:38
  • @robertc; i wouldnt consider it personal. Its private, secret, or whatever, but not personal (like your age, weight, sex, name, address). A password does not identify you specifically as a person (unless your password really sucks :-) – Sirex Aug 08 '11 at 12:38
  • 1
    @Richars +1 for countering AviD? – Nic Oct 27 '17 at 13:58
320

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

Mr Tired
  • 3,211
  • 1
  • 12
  • 3
  • 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 Jul 26 '11 at 22:31
  • 182
    never attribute to malice what can be attributed to ignorance – aldrinleal Jul 26 '11 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 Jul 27 '11 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 Jul 28 '11 at 01: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. – Koos van den Hout Jul 28 '11 at 13:57
  • Companies that do PCI auditing also offer ancillary services, among which is to report on their success in trying to socially engineer you. This smells very much like what is happening to you. You are on solid ground to simply not provide the information. – Brian Deacon Aug 01 '11 at 14:50
  • I must admit that I'd be inclined to think this is a scam too. Laying on the pressure, making illogical demands (6 months compliance with a 2-week-old policy), and persisting in the face of all evidence to the contrary. Are you sure this guy is even known to your provider? @eds it *would* be possible if the OP *was* storing plain text, in which case the scammer would be all win. – Benjol Aug 03 '11 at 13:56
  • 3
    @Benjol In that rare case, yes, but still, I think by the point that the security guy saw this thread, surely the OP would have "passed the test" or the scammer would realize it's not going to happen... but he just kept truckin' along – eds Aug 05 '11 at 15:01
  • @aldrinleal Malice is actually the more generous assumption in this rare case. – jpmc26 Mar 10 '17 at 04:34
300

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.

Community
  • 1
Joseph Kern
  • 9,809
  • 3
  • 31
  • 55
  • 51
    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 Jul 25 '11 at 15:01
  • 20
    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. – Joseph Kern Jul 25 '11 at 15:22
  • 1
    I agree sending fake data is unethical and undermines the entire auditing system -- if people rely on your data being accurate and you send false data then the audit is broken. I edited my post to get it under the char limit; and on reread that point got edited out. I wanted to also say that its downright stupid to fake this data (e.g., passwords) as its easily checked and once found that its faked, responsibility falls solely on you. (Its like how murder is unethical on its own; but its even stupider to do it in a manner where you will get caught.) – dr jimbob Jul 25 '11 at 17:03
  • 14
    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 Jul 25 '11 at 17:06
  • 12
    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. – Joseph Kern Jul 26 '11 at 21:17
  • 1
    sometimes, you just have to get through the day. – AJ. Jul 29 '11 at 15:02
  • 1
    I really think it's wrong to use the argument "I have be in this industry for X amount of year" as the only argument to prove oneself. One can be in an industry for X amount of years but never learn new things. The auditor may still be living in his dream world. – Alvin Jul 30 '11 at 03:40
  • 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 Jul 31 '11 at 23:30
  • 3
    Kudos for injecting that. I think OP had already crossed into the realm of impossibility and was simply writing carelessly. However carelessly walking off a cliff is still walking off a cliff. Wonder what ever happened with this. – T.Rob Jan 11 '13 at 18:54
252

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

womble
  • 95,029
  • 29
  • 173
  • 228
  • 9
    ...an auditor that wanted access to an AS/400 via SMB?...why? – Bart Silverstrim Jul 23 '11 at 00:27
  • 3
    Because his auditing procedure required him to check that the default access permissions (allowing anonymous users to get the share/printer lists) had been turned off. Until his tool could verify to him that this had been done, he couldn't sign off on the audit. – womble Jul 23 '11 at 01:06
  • 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 Jul 23 '11 at 02:38
  • 52
    @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 Jul 23 '11 at 02:44
  • 2
    I've heard it called GWAT -- "Goober With Auditing Tool". – womble Jul 23 '11 at 03:11
  • 2
    Actually, not just older passwords in plain-text, but also new ones: "An email sent to him every time a user changes their password, containing the plain text password" – James Skemp Jul 23 '11 at 10:49
  • In some sense, I have access to an AS/400 via SMB. It is a single directory that is exported to a Windows server (I don't know via what means) and is accessible via SMB because it is then shared again by the Windows server. – Confusion Jul 23 '11 at 15:10
  • 12
    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 Jul 23 '11 at 23:03
  • 18
    "You have 5 minutes of experience repeated hundreds of times" --- ooooh, that's going straight into my quote collection! :D – Tasos Papastylianou Aug 31 '16 at 18:56
190

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.

Jimmy
  • 1,909
  • 1
  • 10
  • 2
  • 28
    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. – Jonathan Watmough Jul 23 '11 at 10:30
  • 5
    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 Jul 24 '11 at 19:42
147

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.

EEAA
  • 108,414
  • 18
  • 172
  • 242
  • 65
    +1 for "...that his cheese has slid off of his cracker." That's a new one to me! – Collin Allen Jul 23 '11 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 Jul 27 '11 at 03: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... :) – Carson Myers Jul 29 '11 at 05:11
  • 65
    @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 Jul 29 '11 at 05:49
  • 3
    @Jason oh no, you're right! – Carson Myers Jul 29 '11 at 06:03
92

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.

ablackhat
  • 1,923
  • 2
  • 14
  • 19
  • 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. Jul 27 '11 at 13:46
80

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.

dmz006
  • 801
  • 5
  • 2
73

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.

Franci Penov
  • 1,148
  • 7
  • 7
  • 2
    Come on, surely this is the point of the audit, social engineering??? 21 up-votes for this?!? – ozz Jul 29 '11 at 08: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? – Franci Penov Jul 30 '11 at 03: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 Mar 20 '12 at 13:50
68

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?

oii
  • 681
  • 4
  • 2
  • 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 Jul 23 '11 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 – Amandasaurus Jul 27 '11 at 16:48
66

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.

postmodern
  • 669
  • 4
  • 2
  • 10
    I would also see it as malpractice, depending on the locale there are probably laws around this too. – AviD Jul 27 '11 at 08:23
61

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!

42

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.

sysadmin1138
  • 131,083
  • 18
  • 173
  • 296
  • 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 Jul 23 '11 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 Jul 23 '11 at 13:28
  • 13
    I disagree with giving anything to this clearly unsecure individual. – Kzqai Jul 23 '11 at 23:17
  • @Tchalvak: no evidence of 'unsecure' or 'idiot'. – user9517 Jul 24 '11 at 09: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 Aug 10 '11 at 03:15
38

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.

jamesc
  • 159
  • 2
  • 6
  • 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 Jul 29 '11 at 08: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 Aug 03 '11 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 Aug 03 '11 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. – Geeky Masters Jul 24 '20 at 17:28
32

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.

Nick
  • 421
  • 3
  • 3
27

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.

wythagoras
  • 111
  • 5
Anarko_Bizounours
  • 976
  • 8
  • 20
21

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.

user9517
  • 114,104
  • 20
  • 206
  • 289
19

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.

reiniero
  • 374
  • 1
  • 7
18

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!

Michael
  • 345
  • 1
  • 2
  • 22
    People shouldn't be asked to provide their own passwords to anyone. – Chris Farmer Jul 24 '11 at 02: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 Jul 25 '11 at 17:24
18

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

Peter Mortensen
  • 2,319
  • 5
  • 23
  • 24
Lucas Kauffman
  • 16,818
  • 9
  • 57
  • 92
  • 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. :) – Martin Sojka Jul 27 '11 at 13:10
  • 5
    90s? I believe unix used hashed & salted passwords in the 1970s... – Amandasaurus Jul 27 '11 at 16:50
  • 7
    I love the fact Lucas changed it to 1960s now :) – rickyduck Aug 04 '11 at 11:11
  • 1
    Did any computer (excepting BASIC tutorials for home micro) system ever have serious passwords and store them in plaintext? – XTL Mar 20 '12 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. – Lucas Kauffman Mar 20 '12 at 13:59
  • Well, it would explain why he has been *in this industry longer than anyone on [this] site* ;) ... with more than fifty years of "experience". – 0xC0000022L Sep 06 '16 at 11:02
  • system ever have serious passwords and store them in plaintext? yes: see https://serverfault.com/questions/116281/in-linux-debian-did-the-passwords-etc-passwd-ever-been-stored-as-plain-text looks like around 1979 Unix did store the passwords in plain text, though according to the link in the mentioned questions it seems to have been at least hashed on linux all the time. – Dennis Nolte Jul 19 '18 at 11:00
14
  • 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.

Vatine
  • 5,390
  • 23
  • 24
12

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.

canadiancreed
  • 296
  • 1
  • 11
11

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.

Istvan
  • 2,562
  • 3
  • 20
  • 28
11

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.

benmmurphy
  • 685
  • 1
  • 7
  • 8
10

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.

Peter Mortensen
  • 2,319
  • 5
  • 23
  • 24
Natwar
  • 31
  • 2
9

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.

93196.93
  • 291
  • 1
  • 4
  • 13
3

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.

Rob
  • 320
  • 1
  • 3
  • 9
0

Short Answer : The stuff tested was you. Would you provide such critical data upon the mindset that you can trust someone with authority.

You could have laughed right upon the request.

jmary
  • 119
  • 5