Storing passwords in a database when hashing doesn't apply

Question

There are a lot of questions on Stack Overflow about how to store user passwords, and the general advice of course is to hash the passwords and compare hashes.

However, imagine you are building a shrinkwrap intranet application (like SharePoint) that people deploy in their own environments. And suppose it requires a username/password combination to access an external service via HTTP (solutions that rely on API keys or federated security aren't supported).

In this case, we can't hash the password because we will need to pass the original password to the web service that we call. Encrypting would be the second best solution, but what would we use for the encryption key? If an attacked compromised the database, presumably they would have access to whatever key is used to encrypt the data in the first place?

If it was really a requirement for you to get the plain-text version of a stored password, how would you approach the problem in the most secure way?

Answer 1

This is actually a really interesting question. I'll join in.

You should encrypt it when storing it. No matter how you look at it it's better than storing it in plain text. Let's say an attacker finds an sql injection ad dumps the db, he still don't hold the encryption key. On the other hand, if he gets access to the server he will probably also find the encryption key.

To improve it a bit, you could store the encryption key in the server configuration. Assuming you are using Apache, you could use SetEnv.

I in my environment are required to enter the encryption key when Apache starts, this is then stored as en environment variable, so the key isn't really stored anywhere on my server.

There is no way, unless you require the user to enter a key to decrypt the password that you will be 100% safe.

Answer 2

You could generate the encryption key from the user's password. (Not their password for the external service—their password for your service.) Since you're not storing their password in plain text, an attacker who compromised your database wouldn't be able to decrypt the passwords. The downside is that you have to ask them for their password (for your service) whenever you need their external password.

Answer 3

You have the question inverted. The problem is not how to let the consumer "view" the password; the problem is how to let the consumer verify authentication.

In your implementation provide a means by which the consumer can provide a password and a username and get either a yes or a no. Then you continue to store encrypted (not hashed) passwords in the database.