Let's say you're creating a website for a customer. This website has its own registration (either combined with OpenID or not). The customer asks you to be able to see the passwords the users are choosing, given that the users will probably be using the same password on every website.

In general, I say:

  • either that it is impossible to retrieve the passwords, since they are not stored in plain text, but hashed,

  • or that I have no right to do that or that administrators must not be able to see the passwords of users, without giving any additional details.

The first one is false: even if the passwords are hashed, it is still possible to catch and store them on each logon (for example doing a strange sort of audit which will remember not only which user succeeded or failed to logon, but also with which password). The second one is rude.

How to refuse this request, without being either unprofessional or rude?

  • 28
    I'm baffled here... They asked for access to the users' passwords, and stated the reason since we know that they are likely to use the passwords on multiple sites? I wouldn't even know how to respond... They aren't just being unprofessional, we're talking fraud/theft of identity here...
    – Max
    Jun 2, 2012 at 10:14
  • 2
    Are they asking for their own password? If not, then simply tell them that it will take time and inform proper authorities. Depending on which sector you are in, different laws may be applicable here. The most stringent one that I am aware of requires you to report this to the relevant authorities without letting the "customer" know that you will.
    – Apoorv
    Jun 2, 2012 at 11:24
  • 1
    you might be interested to read this discussion at SF: serverfault.com/questions/293217/… (about request for passwords from security auditor)
    – gnat
    Jun 2, 2012 at 14:34

6 Answers 6


Tell him the first part. That you are storing the passwords in a hash. And that all password systems work this way. The administrator can change passwords, reset passwords, but can't read passwords. If your customer is knowledgeable about programming, they may know that you could intercept the passwords before the hash.

Now move on to the second part. Does the site have a privacy policy or terms of use. Using the site to collect the passwords would be in violation of most of these policies. If the customer is insistent of collecting this information, explain that this would render his site useless and a ghost town if the community couldn't trust the site.

If it becomes clear that their intent is to steal passwords. Run. Find a new job or a new contract. If you work for a company on this contract tell them what you know.

  • As I pointed out in the question itself, depending on the sector in which you are working (banking for example), not brining the policy gap to the attention of the regulators (FED for example) makes you criminally liable. Many sectors have similar laws (may be not so harsh). So the run and find a new job advice may not be so good after all.
    – Apoorv
    Jun 2, 2012 at 15:46
  • Could you provide a link for this law? That seems like it would discourage a lot of whistleblowing. Jun 4, 2012 at 13:51
  • @ErikReppen: Why would being criminally liable for not whistleblowing discourage whistleblowing?
    – Brian
    Jun 4, 2012 at 19:26
  • Because if I understand Monster Truck correctly (in answer comments), you're held accountable for telling the customer you're contacting the authorities. But what if that's the first thing you told them when they made the request? It also smacks of entrapment via proxy. If somebody would have warned them, resulting in them stopping the criminal behavior and the feds are trying to prevent you from doing that, how is that different from the feds themselves encouraging them to break the law? It's stupid to put consequences on whistleblowers for not doing things exactly the way they want it. Jun 4, 2012 at 20:42

Does the web site have a "Privacy Statement"? And does that statement include something about handing out "sensitive information"?

In that case I would probably say, "I am not at liberty to hand out sensitive information about the user's. That is in clear violation of our own privacy statement!" (The exclamation mark here is important). If you don't have a privacy statement, I would say the same, except for the last sentence.

The persons who ask such questions shouldn't be given false excuses, such as it is technically impossible. They should be educated in the truth, the user's passwords are private, and it is morally and ethically wrong (and probably also illegal as someone mentioned) to gather them from the system.

  • +1 for not handing out false excuses. Better to cut straight to illegal/unethical chase where morons are involved. Jun 4, 2012 at 13:55

Just say that you don't want to experiment life in prison :) Because you know what they ask you, if it's clearly for an illegal use of users passwords, will lead them to a lot of big problems. I think the best way is to try to teach them why it's really bad to do things like that.

But the real problem is, imho, the fact that you work for thieves while you dislike thieves. Instead of finding a way on how to not be too rude with people you dislike, wouldn't it be better if you just stop working for them? I would suggest that you add some clauses about what you are not ready to do in your futur contracts in order to avoid that kind of situations.

Anyway the fact that you're not ready to do what they ask you to do because that's illegal honors you.


Of course you want to be nice, you could indicate that this request is an unusual request and that it requires approval from higher authorities. It would be nice to explain the impact of this act on the organization and the users. This is to ensure that bot you and the customer are in full understanding of the situation. You must keep everything in writing of course.

You could phrase the situation in a policy statement and ask the major stake holder/manager of the system to approve or deny the policy and use that as a backup documentation for your response to the request. You may also want to add to it the fact that users will be notified of the fact that their passwords are not secret.

It is all a mater of policy, nothing more and nothing less.

  • 2
    That's not just a matter of policy as the customer clearly wants to stole the passwords. No developer can be asked to be an accomplice of such a thing. It's hard to call the police on this and it's probably hard for MainMa not to be rude but he cannot comply, whatever the policy and stackholders say. Jun 2, 2012 at 10:30
  • @dystroy, well, we are not sure of the role of the person who is asking for this information. Any thing is legal as long as there is a law to say it is. We are in a world where even killing is justifiable under the law.
    – NoChance
    Jun 2, 2012 at 11:32

Surely you are only storing hashed passwords so it is impossible. If not you have bigger problems. So that is the correct response.

  • 1
    There's an opportunity, however, before the passwords are hashed. The browser sends the password to the server in plain-text, and the server-side code (which MainMa is responsible for) receives it in plain text.
    – user16764
    Jun 2, 2012 at 19:41

Think I would first say that they are one-way encrypted, and then move on to requiring a written (on headed paper) request (from whoever is in charge) so I can present it to the police/FBI (or whatever country's equivalent is relevent)/etc if and when required. Stapple that to a copy of emails in both direction, then the ball is in their court. I can't see any company of any regard requesting this, so it's probably an individual and they would probably back down on the request.

If they give me the paperwork, then it's their data, their request, if they break their own privacy policy or the law, then it's their head.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.