Securely storing credentials that can't be encrypted

Question

I have a client that\'s running an aggregator of information from multiple accounts. The database needs to store usernames and password to other websites in a way that can be us

Answer 1

Anything you can do to use your credentials, an attacker can as well

What does obfuscation actually buy you? Time. The data is there after all, as is your scheme for using it yourself. It's only a matter of time for someone to figure out what your scheme is. This all depends on your level of paranoia as well as an assessment of the level of risk that you're comfortable with. In particular, how you store any credentials should depend on who has access to the machine running the database.

Eventually rubber has to hit the road though, so go forth and conquer. Don't completely knock obfuscation. Just make to sure to couple it with smart practices.

Approaches and Suggestions

Generate per-application API Keys for each account, to be used by the machine

If you can generate API Keys from the third party accounts, this would give you the ability to revoke access to the accounts without shutting all potential applications out. A lot of services have these types of API Keys (Google, Twitter, StackExchange, Facebook and many others).

You simply setup an "application", then use a consumer key and secret as well as an access token and access secret. The machine just has to store these credentials. If a compromise happens, you just have to revoke that set of keys. Additionally, these allow you to specify the permissions per account.

Use a per user password for their set of credentials

When a user logs in, only then do you unlock their set of passwords. To do this you would generate a key based on a proper hashing scheme and a verification check that occurs several hashing steps ahead of the key.

Encrypt it on disk anyway

You could always encrypt the credentials with one key. Then you only have one key to protect (that protects all the other secrets). You would then have to decrypt before accessing your other credentials.

Store the secrets in the system's keyring

On Linux, use the gnome-keyring. Then you can make simple Create-Read-Update-Delete calls, treating it as a password database. The Gnome keyring is based on the PKCS#11 standard.

The gnome-keyring has an API for saving to the keyring and retrieving items.

/* A callback called when the operation completes */
static void
found_password (GnomeKeyringResult res, const gchar* password, gpointer user_data)
{
  /* user_data will be the same as was passed to gnome_keyring_find_password() */
  // ... do something with the password ...
  /* Once this function returns |password| will be freed */
}

static void
find_my_password()
{
  gnome_keyring_find_password (GNOME_KEYRING_NETWORK_PASSWORD,  /* The password type */
                               found_password,                  /* callback */
                               NULL, NULL,     /* User data for callback, and destroy notify */
                               "user", "me", 
                               "server", "gnome.org",
                               NULL);
}

On Windows 7+, use the "Encrypted File System" (EFS) feature. All the files are encrypted with a certificate with is in turn protected with your Windows password.

Don't let this lull you into a false sense of security though. If this is a server that it's running on, if someone gets network access to the box they have access to the keyring data themselves as well.

Set up a remote machine that grants access

Can you set up a machine that would grant access to credentials or an unlock key using public and private key pairs?

On hashing

If you hash the usernames and passwords, you're not getting them back. Hashes are designed to be one-way functions.

You could encode the data for obfuscation though, but I'm not recommending that.