I'm looking for an answer to give to management of a project I inherited after I was observed doing manual password replacement using a visual tool (via SSH tunnel).

Their question:

Why encrypt password fields if you can see all the other data anyway, including names and emails?

Their question comes from their frustration that we can't just give people a new password (admin features are broken). They don't understand the benefit of having these encrypted passwords when, from their perspective, all the rest of the data is available to an administrator anyway. I wanted to give more reasoning than just it's good practice to not store clear passwords.

Further context - the password reset feature was apparently not working so I was replacing the user password by copying the encrypted value from a dummy account. This is what the manager saw me doing, at their request, and then wanted to know why it was worth having our lives made more difficult by encryption.

Yes I know that implies the current password encryption logic needs work - let's just say this is among the least of the problems from the pretending-to-not-outsource original developer. (I'm using the term "encryption" here because I don't know if the code is hashing or using a reversible form of encryption - encryption is actually the broader term for the nit-pickers.)

The SQL database is behind a REST API - they aren't exposing it directly. That's one of the few sins not committed so far, sigh.

  • 3
    If management is expressing interest in understanding this topic, taking a moment to illustrate the difference between hashing and encryption is a golden opportunity. Commented Dec 23, 2017 at 5:01
  • Is your question, "how do I explain to management why passwords are obfuscated when no other personal data is obfuscated?" If so, then the answer is purely about authentication, and not about "personal data". You have a valid, legitimate reason to process personal data in order to provide your service. You have absolutely no legitimate reason to know what the password is.
    – schroeder
    Commented Dec 23, 2017 at 11:22
  • the broader term is "obfuscation" which covers hashing, encoding, or encryption, especially when you don't know which is being used
    – schroeder
    Commented Dec 24, 2017 at 11:48

2 Answers 2


Services need an explicit, specific, and legitimate reason to collect and process data. Passwords are very private personal information that no service has a business need to know. In fact, many industry and government regulations state that services have an obligation to properly protect user passwords as highly sensitive personal data. Check to see if there are specific regulations for your country and business.

In addition, knowing such a personal and private user secret exposes your company to liability. Any user can claim that any action that was performed under their authentication was not performed by the registered user but by your company. This is not a risk you will likely want to take on. And, seeing that it is unnecessary, there is an even smaller legitimate reason to take on this risk just for the convenience of password resets.

Passwords are the only mechanism we have at the moment to keep the authentication process clean. Once you start messing around with this very delicate mechanism, everyone loses.

The answer to Administration is simply, "We have no legitimate need to know the passwords, and knowing them exposes us to liabilities."


Passwords should be hashed (not encrypted - encryption implies that it can be reversed) for two reasons.

The first is that users are negligent and keep using the same passwords for different systems. No, they should not do this, but many people do it nevertheless. So when your password database gets compromised, people can not just log into your user's accounts on your system but also to accounts in any other system where they use the same username&password combination.

Now the suits will ask about the business impact of that risk. After all, it doesn't affect their profits if users get hacked on some completely different service owned by a completely different company. The only argument you can provide here is the Public Relations argument one.

The second problem are internal attackers. When employees can see the passwords of any users they don't like, they can log into their accounts, impersonate them and wreak all kinds of havoc with them.

Now the suits could argue that a rogue employee has even more effective ways to harm users and that they will be fired if they try. But they forget that employees also have a private life. When they log into user accounts from outside the company (and sufficiently cover their tracks), there is no way to find out who it was. Or even find out that it was an employee and not someone who obtained the password from hacking some cleartext password database of a different company.

You must log in to answer this question.

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