5

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.

4
  • 2
    That's what OAuth and similar technologies are for. There you only get a token with limited access. Feb 16 '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. Feb 16 '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? Feb 16 '16 at 22:28
  • 1
    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? Feb 16 '16 at 22:36
10

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.

8
  • It's not for Dropbox, it's from GitHub. I'll look into whether they've got OAuth. Feb 16 '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. Feb 16 '16 at 20:05
  • 3
    @LukeTaylor You're in luck...GitHub does support OAuth. :-) I would definitely look into using that.
    – Xander
    Feb 16 '16 at 20:17
  • Even if I only need to control one account, which remains constant? Feb 16 '16 at 20:17
  • 3
    @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 '16 at 20:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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