How to store / not to store passwords

Question

I am building an web site which will allow users to aggregate the information stored in their online profiles ("data feeds") in one place.

I am wondering - what is the accepted (from a secureness point of view) way to store user name / password information in a my database?

Normally I would derive a salted-hash value from a password and would store this, but that obviously would not work in this case, as "data feeds" websites would need an actual password.

Storing the credentials it in a clear text is not an option, as it would be a huge security risk.

Not storing passwords in a database, asking users to type them in at the beginning of each session and then keeping them in a in-session memory does not seem like a viable option either, as it would be too much trouble for users to enter the same passwords many times again and again.

So far it seems that the only option is to encrypt passwords somehow, but I don't know what are the best design patters for such option.

Or perhaps there is way to deal with that problem, I haven't even considered ...

What would you recommend?

Answer 1

As you are effectively providing a (limited) online password manager service, you could have a look at how the off-line password managers store the passwords for their users.

My napkin-design for such a feature would be to store the password in the database using a symmetric cryptographic encryption, where the key is either provided by the user or derived from a password that the user provides. This way, the user only has to provide a single password at the start of the session, regardless of the number of data feeds that get unlocked that way.

Answer 2

I think what you are looking for is what is known as SSO (Single Sign On):

Source: Wikipedia

a property of access control of multiple related, but independent software systems. With this property a user logs in once and gains access to all systems without being prompted to log in again at each of them. Conversely, Single sign-off is the property whereby a single action of signing out terminates access to multiple software systems.

The challenge of implementing single sign on is that you have to provide the implementation details for each unique type of authentication mechanism that all systems seem to use. Typically in an OOP application one would write Authentication Providers that know how to retrieve credentials and interface with outside system to where your system initiates and performs the "handshake", and then retains this trust for the remainder of the session.

A one-way hash like a salted digest won't work but you already know that. Strong two-way encryption is necessary, but you will need a key to perform this. Store the encrypted credentials in the database on a separate machine and lock down that servers firewall only exposing the required ports. Keep the key on the application server in an obfuscated non-obvious way. Keeping the key on a separate machine from the one that houses your database and encrypted credentials reduces the risk if a single machine becomes compromised. Any additional steps you can think of that will further obfuscate this will help with security.

EDIT: User Bart Van Ingen's suggestion about the key is the ideal situation, where the user provides the key when they log in, absolving you of the responsibility of maintaining the key/keys on your own system.

Answer 3

The general way is to use a one-way hash (plus salt, of course, and when I say "hash" here you should always mentally append "plus salt"), store the hash in the database. Then, when the user enters a password, you hash that too (using the same hashing function) and compare hashes.

However, I would not recommend that you build your own security system. The reason why is that security is hard, you don't know more about it than those that have already built security systems (and the fact that you're asking this question confirms it), and you shouldn't be thinking that you can do a better job than them.

Does your web server software provide a security system? Does your OS provide a security system? If so, and if you can, then use those instead of rolling your own. They're tried and tested, they've been worked on by security experts, they're designed to meet requirements of security certification, and no matter what you think, you can't write a better one yourself.

If this is not an option then look to use something like OpenID, Google, whatever. Just use something that's already been proven to work and that has the bugs (and not to mention security risks) already worked over.