Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Say I'm creating a public web service which needs to write files to a Dropbox account (just an example). It needs to write files to one central account, not one per user. This service needs to access the Dropbox account with a password. I want the web service to be able to access my Dropbox account without exposing the password publicly. How might I accomplish this? If I encrypt the password in a separate file, the encryption key would still need to be in the public file that contains the code for the service.

share|improve this question
That's what OAuth and similar technologies are for. There you only get a token with limited access. – Steffen Ullrich Feb 16 at 19:49
If you don't want the password publicly-available, then don't give anyone the password. Your service can make use of passwords without making them visible to users. – Christopher Schultz Feb 16 at 22:27
How? Can't anyone who presses "View Source" on their browser then go through "page resources" and see the script which contains the password? – Luke Taylor Feb 16 at 22:28
If you expose the password in your scripts, then yes, anyone can do that. But you wouldn't expose the source code to your scripts to just anyone wandering by your web application, would you? – Christopher Schultz Feb 16 at 22:36
up vote 10 down vote accepted

If this is really for Dropbox, don't. Dropbox has an API and OAuth. Use Dropboxe's OAuth provider to get an OAuth token for the user instead, and you can store that. Do not take, or store the user's credentials.

If it is for a service that does not expose an authorization provider, and you do actually need to store the credentials on the user's behalf, you must do so very carefully. Preferably they'll be stored in a separate service, with only authenticated sessions being presented back to your main application to reduce the attack surface area. The credentials themselves should be stored in an encrypted format, and the encryption key should be stored as securely as possible, preferably in an HSM.

When you have data as valuable as authentication credentials for third-party services, your duty of care to protect those assets is very, very high. Defense in depth is going to be critical, as is limiting access, logging and monitoring, and detailed threat modeling to understand the scope of your attack surface.

share|improve this answer
It's not for Dropbox, it's from GitHub. I'll look into whether they've got OAuth. – Luke Taylor Feb 16 at 19:52
My application really only needs to communicate with one central account, not one per user. Can things be simplified with that? I realized that wasn't clear in the question. – Luke Taylor Feb 16 at 20:05
@LukeTaylor You're in luck...GitHub does support OAuth. :-) I would definitely look into using that. – Xander Feb 16 at 20:17
Even if I only need to control one account, which remains constant? – Luke Taylor Feb 16 at 20:17
@LukeTaylor If you're going to be accessing GitHub via the APIs, I would probably still use OAuth, as that is the preferred supported mechanism, and the only mechanism they recommend for production applications. – Xander Feb 16 at 20:21

Your Answer


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.