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.

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.

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.