My company is currently engaged in a security audit framed as a pentest. They've requested all admin passwords for every one of our services and all source code of our software. They want logins for Google Apps, credit card processors, GitHub, DigitalOcean, SSH credentials, database access, and much more. Note, we've never signed a single NDA (but have been provided a statement of work) and I'm very reluctant to provide this info to them because of this.

Is this normal for a pentest? I assumed it would mostly be black box. How should I proceed?

"UPDATE* We now have an NDA. The contract does, however, say that we can't hold them liable for anything. Still not sure if this is the right move to continue with them. In my experience, their requests aren't normal even in white box audits, and their statement of work reads in a way that doesn't make it clear if this is a white box or black box audit.

  • 220
    Closely related: Our security auditor is an idiot. How do I give him the information he wants?
    – Jeff
    Commented Oct 25, 2017 at 17:50
  • 130
    Hey, I want to audit your company: please send me all your admin passwords. Just edit your question to list them all ....
    – schroeder
    Commented Oct 25, 2017 at 19:05
  • 111
    Wait, what? You've never signed an NDA with that security company? Back the heck off right now and get that NDA signed before ever moving forward. Sounds to me like it's a fake company masquerading as a real one, to see if they can get any information from you. If this is a real legitimate company, then the auditor is trying to see if you're dumb enough to provide that information. If you provide even a little bit of it, you've failed the audit. However, this is incredibly unprofessional and should never happen. Commented Oct 25, 2017 at 20:32
  • 262
    This is the first test.
    – Seth R
    Commented Oct 25, 2017 at 21:16
  • 91
    I've been a pentester for five years. We don't touch a damn thing until we've got an agreed scope, timeframe, signed contract, and NDA in place. These formalities protect both parties and nobody should hand over any data or touch any systems until they are properly completed. Anyone who requests this kind of information without legal agreements in place and absolute necessity of access is (at best) a massive technical and legal liability to themselves, their organisation, and yours. Stay the hell away from these cowboys.
    – Polynomial
    Commented Oct 26, 2017 at 2:31

7 Answers 7


Is this normal for a pentest?

Absolutely not. Best case scenario: they are performing "social engineering" penetration testing and want to see if you can be pressured into fulfilling a very dangerous action. Middle-case scenario, they don't know how to do their job. Worst-case scenario they are only pretending to be an auditing company and fulfilling their request will result in an expensive breach.

In the case of a code-audit the company will obviously need access to source code. However I would expect a company who provides such services to already understand the sensitivity of such a need and have lots of forms for you to sign, and to offer to work in a strictly controlled environment. A reputable security company is going to be concerned not just with protecting you (because it is their job) but also with protecting themselves from untrustworthy clients (Our source code got leaked right after we hired you: we're suing!!!!). All this to say: any reputable security company that doesn't have you sign lots of contracts before going to work is not a reputable security company.

I can't imagine any circumstances in which handing over access to any of those things would be a good idea.

Edit RE: hidden contracts

A few have suggested that the company might have simply not told the OP about any relevant contracts/agreements/NDAs. I suppose this is possible, but I want to clarify that the lack of a contract isn't the only red flag that I see.

As someone who has built e-commerce sites and business software that has required integration with many CC Processors, I see absolutely no benefit to giving someone else access to your CC Processor. At that point in time they are no longer penetration testing your systems: they are penetration testing someone else's systems that you happen to use. Indeed, giving out access credentials in such a way likely violates the terms of service that you signed when you started using your CC Processor (not to mention the other systems they are requesting access to). So unless you have permission from your CC Processor to hand your credentials to a security auditing company (hint: they would never give you permission), giving them that access is a huge liability.

Many others here have done a great job articulating the differences between white-box and black-box testing. It is certainly true that the more access you give security auditors, the more effectively they can do their jobs. However, increased access comes with increases costs: both because they charge more for a more thorough vetting, and also increased costs in terms of increased liability and increased trust you have to extend to this company and their employees. You are talking about freely giving them complete control over all of your companies systems. I can't imagine any circumstances under which I would agree to that.

  • 69
    Completely agree. At best, I'm hoping it's a clumsy way to prove a point about social engineering. But even then, I would not do business with such a company. any reputable firm will have a contract, and an NDA, and various assurances to protect both you and them before starting an engagement like this.
    – JesseM
    Commented Oct 25, 2017 at 17:54
  • 6
    Good answer. OP may also have obligations to his other service providers not to share his password with other parties. That being said, it may be acceptable to create a new user account specifically for the pen testers, with their own password that they would manage, with limited permissions, on a case by case basis.
    – John Wu
    Commented Oct 25, 2017 at 20:09
  • 2
    @jesseM One remaining possibility is that contracts and NDA's are signed and the OP doesn't know about it. We have had situations where we would be doing pen testing that was done without the knowledge or with different kinds of limited knowledge of the participants. (I.e. only the CEO, CSO and CIO would know about it. It is very tricky to do this right and there need to be very good escalation processes in the organization though, otherwise you risk a lot of trouble when people don't react correctly and things stop working.)
    – DRF
    Commented Oct 26, 2017 at 11:06
  • 1
    @DRF even in the context of the OP not knowing about contracts, these requests are unreasonable. Access to their CC Processor? I see no reason why a security auditor would need that. It is a huge liability for both parties. Even if you are trying to check that they are following best-practices in CC processing, you don't need access to their CC Processor to do that, and requesting access is a clear violation of best practices. They are asking for too many highly sensitive items for this to be anything other than bad. Commented Oct 26, 2017 at 11:24
  • 2
    @DavidMulder That is actually a very valuable service: for comparison, it is amusing to google "another amazon aws leak" to see all the instance of people leaking critical information because of poorly configured hosting configurations. That being said, I don't think handing over passwords is the way to fix that one. If it came down to it I think it would be better to let them remotely connect to an office computer and watch everything they do. It would be a more valuable learning experience like that anyway. Commented Nov 2, 2017 at 14:57

How should I proceed?

Don't proceed with them. The way they act is unprofessional. Pentests carry risks for both parties, and it doesn't seem they did anything to address them.

First, you should absolutely not hand anything over without a written contract (including an NDA). It's surprising they routinely do business like that. How do they know the exact scope? Under which terms do they get paid? Will they just clam they're "done" at some point or is there a timetable? Do you get a proper report? Who pays if they cause damage? Are they insured in case they lose your credentials to a third party? How will you know if a future breach is part of the test or an actual attack by someone else? Even if you trust them, these questions should certainly be answered before you kick off a pentest.

And it's not just you, they are putting themselves at risk. If you never clarified the scope, they might be attacking some of your systems without permission, with potential legal implications.

I assumed it would mostly be black box.

Both black and white box tests are common and each approach has its own advantages. But if the mode of testing never came up, it seems like there has never been a discussion about what should be achieved by conducting a pentest in the first place. A professional contractor would have assisted you with figuring out the right conditions and methods.

(One great first question to a potential contractor is asking them for a sample pentest report. It will give you an initial idea about how they work and what results you may expect.)


Prior to any penetration test there should be a Scoping and Rules of Engagement document(s) that is signed by both parties. These documents should describe in detail what will be tested and what methods have been agreed upon by your company and the contractor. If you have not gone through this discussion with your contractor, discontinue the engagement and seek other professionals.

As a penetration tester, I have asked companies to provide accounts or laptops that they would provision a normal user. This allows to test from a malicious employee perspective. However, this is all agreed upon prior to the test in the Scoping and Rules of Engagement.

Just my 2cents.



We are doing a full pentest at my work. It was explicitly stated by the pentesters that they don't even need the login/password for anything. We stated that it was great since we'd never release anything to them before hand. There are 3 main types of pentests: white box, grey box, black box.

White Box is that you give them all information and they find problems with your software, network, etc.

Grey Box is that you give them some details of what you want them to pentest. We used that since they'd have no idea which external wireless ISP we were using. We told them to do an external test first so we gave them a few IPs and they easily broke in.

Black Box is that you provide them nothing and they have to find everything on their own. After that they can do their pentest on the external IPs. For internal testing, it is different. They will be inside your network running nmap and other intense scans on every target they come across. This is the most difficult, but the best in my opinion.

  • 1
    "We told them to do an external test first so we gave them a few IPs and they easily broke in." -- Where you work at?
    – Daniel
    Commented Oct 28, 2017 at 14:37
  • 7
    @Daniel You mean, "What's your IP", don't you? :)
    – BenjiWiebe
    Commented Oct 30, 2017 at 14:10
  • @BenjiWiebe I see what you did there, but I wouldn't dare going down such shady paths. I asked for the company name to stay clear from them; I have no desire to penetrate anyone as it is against my nature.
    – Daniel
    Commented Oct 30, 2017 at 23:10
  • @Daniel breaking in is only the first step. Exploiting the holes found is another step. Try phishing your own company. Implement policies and enforce them. I work for State Government.
    – rockower
    Commented Nov 1, 2017 at 0:35
  • @Daniel "I have no desire to penetrate anyone as it is against my nature." I see what you did there
    – Bas
    Commented Nov 1, 2017 at 13:03

My company is currently engaged in a security audit framed as a pentest.


Note, we've never signed a single NDA or other contract with them yet, and I'm very reluctant to provide this info to them because of this.

The use of "engaged" in this context implies a definition of "enter into a contract to do something." This leaves me wondering if the conflicting statements are accidental or if you are not the entity within your company that has engaged the security company.

If the latter, there may very well be contracts/agreements of which you were not made aware. This would not be unusual, as many of the penetration tests where I have been on the receiving end conceal the specific details of the test from employees so they don't take any "abnormal" actions to protect against the test(s).

If this is the case, then do with the request what you would do normally with such a request. Tell them "no" and if they push back ("but it's required for us to perform the penetration test") then run the request (in writing) up to your supervisor providing your concerns. If your supervisor tells you (in writing) to release this information, you should then be in the clear as they may have a better understanding of the test than you do. If your superiors are unclear run it further up the chain of command and/or push for them to request guidance from the entity that engaged the security company.

However, if you are the entity who has engaged the security company then I (like the other answers here) would have serious concerns. If you feel it may still be worth pursuing (or are concerned that they will make some sort of "breach of contract" claim), then I would suggest you use a means of evaluating if this is a social engineering test. For instance, you could generate a list of fake admin accounts and passwords. Provide this to them, say you are still working on the rest, and you will send it along as it is ready. Then see how they respond.

If it is just a social engineering test, all they need is to see proof of this type of information being leaked (which you can show later are faked accounts). A responsible security company shouldn't need any more of the requested information and should stop you from providing it ("Looking at what you provided, I think this should be sufficient to let us proceed; don't worry about the rest unless it turns out we really do need it"). If they don't stop any further information, disengage immediately.

More information could only cast suspicion on any penetrations they perform from that point forward (i.e. it is easy to penetrate a system if you have admin access) and/or expose them to potential intellectual property lawsuits (i.e. leaked source code, etc).

  • 10
    Fake accounts and passwords are an excellent suggestion. They would be even more effective if they were accounts that led them into a honeypot, so you could monitor them for abuse. Commented Oct 26, 2017 at 15:55

Coming at the question from a slightly different angle:

Are you the CEO or CTO?

No? Then do not give the auditors any passwords. Ever.

Put an information package together and forward it up the chain to your IT Manager, CTO, CEO, or whatever. To put it bluntly, it's their job to make those sorts of decisions (and to take the consequences), not yours.

If your boss says, "No, you send it." then answer, "As an employee, I'm not comfortable releasing such dangerous information to a third-party."

If you are, in fact, the CTO, then take advice from the answers above.

  • You might also add in writing that your professional advice is not to release the credentials, but that you respect that it is the CEO's decision.
    – o.m.
    Commented Nov 4, 2017 at 9:09

Validate your assumptions.

If this is supposed to be a black box test, they should not get or require any passwords whatsoever.

If this is supposed to be a config review, or white box tests, some passwords should be handed over. The correct procedure is to change them before the test to something unique (random string), and then change them again after the test.

Check with your management and explicitly ask if proper NDAs and contracts have been signed.

Is this normal for a pentest?

The scenario as you described it is unusual, but not entirely implausible. It all depends on what exactly was agreed for the test scope and activities.

I assumed it would mostly be black box. How should I proceed?

Check with the manager responsible for signing this pentesting team. Your CISO or CSO or IT manager or whoever it may be. Voice your concerns and ask if this approach was agreed upon.

Giving Passwords / Source Code

Personally, I would not give any passwords or source code to anyone without a proper NDA signed. I would also never, ever, give them the actual passwords. In all the pentests I've been involved in, on both sides as both customer and project manager (I'm not a pentester, but I've managed pentesters) there were always user accounts created for the pentest and passwords changed. We even recommend to our customers to change them after the test is done (some don't, that's always a sad finding for the next report).

Password Strength

As for what some answers wrote about "evaluating password strength" - that's a load of hogwash. Yes, there is a "best practice" on good passwords, which some guy pulled out of thin air some decades ago and is terribly sorry for today. All the math on the subject is full of holes and unverified assumptions and a lot of password policies actually reduce the search space instead of enlarging it. The only real test for password strength has two parts: One, get the top 10,000 or so passwords from one of the 20 or so lists that float around the Internet and use that as a blacklist. Two, run the same cracking software that bad guys use (most of them are Free Software) on your password hashes. If your instance of John cracks it, so will theirs.

  • 1
    most of this is covered by the other answers - your password strength section is based on a faulty assumption; if the same admin password is used in multiple places, then that is not a strong password, for instance - and yes, automated password audits do exactly what you outlined, so I'm not sure where you are going with this 'counter argument'
    – schroeder
    Commented Oct 26, 2017 at 13:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .