Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
    
Why would any legitimate 3rd party application require access to a user's mailbox? If (okay I mean when) any site asks me for my password to any other site - I stop using that site immediately. I don't see any decent reason for it - but if in your case there is good reason, please elaborate. As it stands now, I find it sounds a lil bit spammy, at best. –  AviD Dec 25 '10 at 19:19
    
There is a good reason. This is a service that users ask for, which works with their email data. I'm not sure I can reveal the details of what is done with the data, but they are mostly irrelevant - if you are concerned that the users don't know about what is involved, or somehow getting taken advantage of - it is not so. I'm not sure why you mention spam - it has absolutely nothing to do with spam. –  StasM Dec 25 '10 at 21:22

2 Answers 2

up vote 5 down vote accepted

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):

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.

share|improve this answer

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.

share|improve this answer
    
The problem is it has to be persistent - i.e. the app should have access to the account in a week, month, etc. I.e. storing the key in memory wouldn't solve it - what if the server restarts, how would it decode the info then? Asking the user is not an option, that's the whole problem - the system should be independent once the user has registered the account. –  StasM Dec 24 '10 at 9:59
    
honeypots isn't a bad idea, though it wouldn't help with the original problem. –  StasM Dec 24 '10 at 9:59

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.