Safer Methods for API Key Storage and Retrieval

[utkonos]

There are a couple of problems with keeping API keys in environment variables. At least on macOS, GUI software cannot access them unless they are set in the software's plist configurations on disk. This is sub optimal. The OS has a keystore that can be used, but I don't see any mention of such in the API documentation about settings.

I read through the code for the Python implementation of the client library for Hashicorp vault and boiled it down to only the exact steps needed for local token authentication. That resulted in this function:

import pathlib
import requests

def getkey(service, name, vault_addr):
    """Get API key for specified service."""
    token_path = pathlib.Path().home().joinpath('.vault-token')
    if not token_path.exists():
        raise FileNotFoundError('Vault token file not found in home directory.')
    token = token_path.read_text()
    headers = {
        'X-Vault-Token': token,
        'Content-Type': 'application/json'
    }
    response = requests.get(vault_addr + f'/v1/apikey/data/{service}', headers=headers)
    if not (apikey := response.json().get('data', dict()).get('data', dict()).get(name)):
        raise KeyError('API key not found.')

    return apikey

However, in an ideal situation, there would be a way via the Python and other APIs to interact with the OS's keystore. The settings GUI would have a configuration box that would serve as a way to save a credential to the store as well as a way to retrieve the credentials for use in plugins etc.

Thoughts?

s = Settings()
s.register_group('vault', 'Hashicorp Vault')
setting = {
    'description': 'Enter vault URL.',
    'title': 'Use Hashicorp Vault',
    'optional': True,
    'type': 'string'
}
s.register_setting('vault.url', json.dumps(setting))

[CouleeApps]

There are a few options for storing secrets, each with advantages and disadvantages:

• There is a SecretsProvider api which is designed for storage of actual secrets, with no UI but with a couple of standard implementations:
  • SecretsProvider["SystemSecretsProvider"] uses the rust keyring crate to store secrets in a system-defined manner. This is probably what you want to use.
  • SecretsProvider["AESFileSecretsProvider"] stores secrets in a file encrypted with AES and some magic key nonsense. The key is based on a per-machine hwid, so it's not settable by the user or enforced by any os protections.
• Settings (as of dev) has an option for hidden password-like entries with the key "hidden": true in the setting description. This is easy to access in the UI, but also stored in plain text in your settings.json and can be pretty easily leaked on stream if you happen to edit your config
• UI plugins can use QSettings and store the keys in either the registry (windows) or Library/Preferences (mac) or ?? (linux). There's no convenient UI for them though, and they are also stored in plaintext.

So my recommendation would be to use SecretsProvider. The docs are a little... sparse... but the actual interface is small enough that usage is simple:

>>> ssp = SecretsProvider["SystemSecretsProvider"]
>>> ssp.has_data("test")  # Check for a secret with a given key (use before get_data)
False
>>> ssp.store_data("test", "data")  # Store some text into a key
True
>>> ssp.has_data("test")  # Now this returns True because we stored data
True
>>> ssp.get_data("test")  # We can retrieve the data (here is where a keychain access popup would go)
'data'
>>> ssp.delete_data("test")  # Clear the data if we don't want it anymore
True
>>> ssp.has_data("test")  # Now it's gone
False