views:

35

answers:

0

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?