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.
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.