What are all of the issues with storing a cleartext password?

Question

I know, I know, cleartext passwords are terrible and you should always store a hash!

However, I'm interested in all of the issues with storing cleartext passwords so I can make a reasonably secure choice. Are there any issues other than the obvious two??

1. Many people reuse their passwords and you're putting them at risk
2. An attacker can now login as the user to your site (although couldn't they just change the hash in the database to be a new password at that point / they already have access to all the information anyways?)

Motivation: If the password in question is randomly generated and only used by the server to authenticate on behalf of the user to a service (an attempt at "single sign-on"), the primary reuse risk is negated. If an attacker compromised the database, they'd be able to login directly to the 3rd-party service. But if having your database compromised at all is orders of magnitude worse than having an attacker gain access to the 3rd-party service, is it still an issue?

DETAILS ADDED FROM COMMENT:
I'm trying to authenticate from a server with health information on it to a 3rd-party Jabber server, so the client never has to know login credentials to the Jabber server. Then authenticated tokens can be passed from the server to the client so the client can communicate directly with the Jabber server. Obviously, access to the health data in the database is orders of magnitude more disastrous than gaining access to the Jabber service.

I'm trying to be careful here because I'm very wary of cleartext, but it seems like the best approach in this particular situation.

Answer 1

I know this does not directly answer your question, but another approach would be to have the application authenticate itself to the service to set up a trusted channel between the two. The app could then just pass identity assertions on behalf of the user, and no per-user passwords would be needed.

The assumption here is that the service is happy to trust the application.

Answer 2

I'm addressing this:

If the password in question is randomly generated and only used by the server to authenticate on behalf of the user to a service (an attempt at "single sign-on"), [the risk of disclosing a password that the user might be using for other accounts] is negated

This is only partially true. If you are just storing a RANDOMLY generated password that is used only by your system, then you only reduce the risk. The reason it is not negated is because if you ever disclose this randomly generated password to your user, they MIGHT end up using this for their real accounts (this happens more often than you may think)

As for the following:

An attacker can now login as the user to your site (although couldn't they just change the hash in the database to be a new password at that point?)

Use a salt. You can even store the salt in the DB, and manipulate it programatically within your code when you compute the hash (You can store salt X, but actually use a manipulation of X when you compute the hash). This way, even if someone can modify values stored within your database, they would not be able to log in unless they knew how you used the salt you stored + password to compute your hash. Since this is single sign on, think about how bad it would be if someone could log in with a privileged account to your service? What doors could that open?

Answer 3

There is also a case where the attacker is only able to read your database. If you have a vulnerability in a select query, i think the only thing the attacker can do is to read data from your database, and then it is obviously a lot better if the passwords are hashed.

Answer 4

To answer your question, here are all the bad things about cleartext passwords I can think of off the top of my head:

1. Passwords easily stolen by rogue employees
2. Easily (and unintentionally) shoulder-surfed and memorized.
3. May end up appearing in cleartext in core dumps, logs, or other unintended places.
4. Passwords can be easily obtained by hackers if they are able to get a copy of your database. This doesn't always mean your database server has to be compromised, by the way (i.e. they could steal a backup or someone's development laptop).
5. May reveal additional confidential information (e.g. if a user uses a variant of his birthday as his password)
6. Immediate reputational loss if an incident occurs or your architecture is ever made public.
7. Fails most levels of compliance for HIPAA, PCI-DSS, etc. Even if it is just for talking to Jabber, since presumably a criminal team would be able to impersonate an end user and use a social engineering attack.
8. Depending on your jurisdiction, may indemnify the hackers against certain legal charges, e.g. it may be illegal to crack the password but not to read one in clear text.
9. Other programmers will laugh at you.
10. Cyber security is only as strong as its weakest link.

To answer your real question, the typical scheme for this sort of thing would be as follows:

1. End user authenticates with your web site
2. End user indicates desire to use Jabber (e.g. clicks a link)
3. Your server communicates with Jabber using credentials that had been randomly generated for this specific user
4. Jabber authenticates your server via IP white listing, client certificates, or other common means.
5. Jabber authenticates the credentials and creates a session for the end user.
6. Jabber returns the session key to your server.
7. Your server returns the session key to the user's browser
8. The browser is now able to use Jabber.

Under this scheme, the credentials mentioned in step 3 are not hashed, since they need to be recoverable. This is unavoidable, and not uncommon; in situations where compliance is involved (e.g. HIPAA in your case), the credentials can be encrypted instead, using a master secret (AES128 is the default choice) held in a secure part of your system (for example, the Windows certificate store or using the Crypto API). Access to the secrets can be enforced via service account permissions; only the specific microservice that talks to Jabber ought to be able to access them, and it should only expose session IDs that is has created, never the credentials themselves.

Note also that you should be thinking about schemes for rolling the cryptographic material every few months or so, or immediately on demand if your system is ever compromised.

Answer 5

There are two primary risks with cleartext password storage.

1. Many people reuse their passwords and you're putting them at risk, if there is a security breach of your site.

2. System administrators, backup operators, and others may now have access to users' passwords. This is poor practice.

Yes, you are right that if an attacker compromises your system and gains full access to your database, then they could modify the hashed password even if you hash passwords. Hashing doesn't prevent modification. In principle, if an attacker manages to gain read-only access to your database (say, a backup gets stolen from the trunk of your car), then hashing is more secure: if you store cleartext passwords, the thief has all your passwords, whereas with hashing, the thief doesn't immediately obtain all of your passwords.

I also suggest reading the other questions in the passwords tag.

Answer 6

I was going to make this a comment, but when I went to write it, I figured it was more of an answer. Clearly this Jabber service feature should be 100% separate from the health information. You need to follow ALL laws about storing health information.

Which leads me to the following thought: Doesn't Jabber support OAuth? The user in question has to at some point know their username and password to authenticate with the third-party Jabber server.

So there are two ways to handle accessing "the jabber" account. If you don't want the user to provide the authentication details then you really only have one option, create the account for the user, and handle the authentication yourself.

You can do this by creating the username and password for the user. You could either use authentication system like OAuth where the client and server exchange information. OAuth allows the user to request the token, then the server grants the token and this allows the client to access the contents. This approval can be taken away seamlessly at any time.

This requires you to be the "user" and provide the information to the server so the client can approve the client's access to the content. So the other solution would involve the user to provide the information once and using a similar mechanic, getting approval until the approval is revoked.

I honestly don't understand the concern. Access to the Jabber service if separate from the health information would not lead to a leak of PII and Medical information.