Storing third-party auth info securely

Question

Suppose there's a multi-user web application that requires access to user's mailbox (on third-party service, like gmail, etc.). This access needs to be persistent. Which means we'd have to store user password. Which creates a vulnerability point - if somebody gained access to such system, he could steal tons of user's mailboxes. Is there any way to reduce the risk in such setup? E.g. for some websites OAuth could reduce the risk since tokens need consumer keys, can be restricted and can be easily mass-expired if something bad happens. But all this is not available for mail servers. So, any suggestions about a good way (if there's any) to store such information in a more secure fashion?

Answer 1

Experience shows that if a site like this is on the public Internet and gets popular enough, it becomes a big target and has a high likelihood of disastrous compromise. Note well the responses in this extensive discussion (about a somewhat different goal):

• How should I ethically approach user password storage for later plaintext retrieval? - Stack Overflow

If you choose to go ahead, make sure you warn your users of the very real risks. Defense-in-depth is mandatory - keep the actual password storage machine off the web, accessed thru the firewall with a very simple interface, built on the most secure platform you can find, with lots of hardening and monitoring, a good IDS, etc etc.

Answer 2

As you say, this is a potential weak point. But how you fix it has a lot to do with the way the application is implemented. e.g. if runs as a java application in a container, then its possible to write the token into the application's heap after it has started. From there its very hard to read back without getting into the memory space of java. For, say, a PHP type platform this is not a feasible approach, possibly the best solution would be to use an environment variable set when the webserver starts up. Admittedly this is a more complex proposition for mainting the POP passwords for thousands of potentials users rather than, say a single database password - but the principle is the same. As for a shared platform....then it really has to go onto the filesystem (see also suphp and open_basedir for php).

However most of this complication vanishes if you ask the user to supply the password. Protecting the session data from snooping is easier than a system wide setting - although there are still potential issues here. If you need to authenticate the user independently of the third-party facility, or you connect to multiple third-parties, then you could use the user's password as part of an encryption key to a stored database of the users tokens.

But instead of asking about how to secure such a platform, you're asking about how to reduce risk. However if you don't control the third-party authentication mechanism, then you don't have the option of using anything other than simply a username/password.

So the only other option you've got, apaprt from ensuring god security at the front end, is to spike your data with honey-pots - then if you see any access to the honey-pots then you know that you've probably been compromised.