Best Practice for Sensitive User Information Storage on Remote Service

We have a desktop and mobile application that is used to access many third party services. These services have some potentially sensitive information - eg Authentication tokens, and in some cases plaintext usernames/passwords.

We want to provide a service to synchronise their settings across multiple computers and devices. That is - they sign into a service we provide, and then that information is synchronised across wherever they're signed in.

We have no way to force the third party applications to stop using plaintext passwords.

There are a few approaches we have considered:

1. Don't ever send passwords or authentication tokens up.

   When a user signs in on a new device, they'll need to 开发者_高级运维re-enter/authenticate the device for each third party service.

   Advantage: Secure, no risk of password/token compromise.

   Disadvantage: Difficult for users.

2. Encrypt the sensitive information using a client-certificate or hardware token.

   When a user wants to sign in, they provide the certificate/hardware token.

   Advantage: Very secure.

   Disadvantage: Huge barrier to entry, difficult to impossible for not-for-profit app to implement.

3. Encrypt the sensitive information using a password that the user provides

   When a user signs in on a new device, they'll be prompted to provide a password.

   If the password is incorrect, they need to re-enter/authenticate all the other devices.

   Advantage: Secure, if the user provides a strong password.

   Disadvantage: If a user resets their password, they need to re-auth the device for all the third-party applications.

4. Encrypt the sensitive information on our servers.

   Advantage: Easy for users.

   Disadvantage: Only marginally more work than plaintext for anyone that grabs the settings tables.

5. Don't bother encrypting anything. (Plaintext storage)

   Advantage: Easy for users.

   Disadvantage: Easy for anyone that grabs our DB to get all the user's passwords/auth-tokens.

My question is: Is there a better approach that we have not yet considered?

---

OK this is a multifaceted question. You have to consider both the security of the information as it is being transmitted across the Internet as well as when it is on your servers.

With regard to case 1, of course it is good not to risk the exposure of passwords, but the application you've created is meant to be convenient for users. IF done correctly, the information can be passed securely without risk of exposure. However, that in mind, implementing cryptography correctly is not a feat that should be taken lightly. In fact, when I say that you should never implement your own cryptography, but use existing time-tested cryptographic libraries paying attention to use them correctly.

As for bullet number two, while you are correct that you should not implement the cryptography yourself, there are many programs and libraries for generating public and private keys and using them to secure information.

You 100 percent need to encrypt the information stored in your database. Every server is insecure given enough time/motivation. Encrypted information however, is possible of being computationally infeasible of decrypting without the appropriate information.