Store account keys securely

[igamigo]

As a temporary solution we are storing the account key pair in the database unencrypted, but we need to decide on a more flexible and future-proof approach as @bobbinth suggested. The main use-case we need to support now is to be able to provide authentication easily (but we will also probably want a way to import/export accounts in the future).

[bobbinth]

A couple of things to consider here:

1. How can we make the scheme more flexible so that it can accommodate various authentication schemes (e.g., multisig, different signature algorithms etc.)? A few things we can do here: a. Rename the table to account_auth. b. Rename key_pair field to auth_info (or something like that) which would contain a serialized version of some struct (or enum) defining possible authentication schemes.
2. What should we do to avoid storing secrets in the database in plain text? One option is to encrypt the data using password, but I wonder what best practices are in this regard.
3. Should we use a single secrete value to derive all subsequent account keys deterministically? If so, what should be the scheme for doing this.

[igamigo]

2. What should we do to avoid storing secrets in the database in plain text? One option is to encrypt the data using password, but I wonder what best practices are in this regard.

I'm not entirely sure what the best practices are specifically in regards to non-interactive CLI tools. We probably don't want to enforce keeping a password on a file and we also want to avoid passing it as a flag in plaintext to the tool. Perhaps an environment variable which the user can decide how to set? There's also the OS services that we can leverage. For wasm environments I guess the password can be entered on prompt.