search

crypto-com / thaler

Thaler Experimental Network; For Crypto.org Chain: github.com/crypto-org-chain/chain-main
https://thaler-testnet.crypto.com
Other
158 stars 80 forks source link

Problem: client-cli requires inputting authentication token #960

Open tomtau opened 4 years ago

tomtau commented 4 years ago

That may make sense for client-rpc. As "cli" is a human interface, this is not ideal, especially if the token can be derived from the passphrase (once in the beginning).

yihuang commented 4 years ago

So, cli simply accept passphrase and derive the token on the fly?

tomtau commented 4 years ago

So, cli simply accept passphrase and derive the token on the fly?

That's one option (just derive it once in the beginning of the command execution) -- another option would be to require setting it in an environment variable (+ have "get token" command that would derive it in the case that the user forgets/loses it).

Maybe the former is a more familiar CLI UX

yihuang commented 4 years ago

There is a auth-token command currently to derive the token.

tomtau commented 4 years ago

I'll close this issue for now -- we can reopen it if more people complain about it

yihuang commented 4 years ago

May I ask why input auto-token makes sense for client-rpc, but not for client-cli? And if the user needs to input passphrase every time, what's the point of deriving different encryption keys? If passphrase compromised, all the keys are compromised.

tomtau commented 4 years ago

May I ask why input auto-token makes sense for client-rpc, but not for client-cli? And if the user needs to input passphrase every time, what's the point of deriving different encryption keys? If passphrase compromised, all the keys are compromised.

client-rpc isn't a user interface -- JSON-RPC API design is a different problem.

Install perhaps any command-line wallet, any command-line password manager, any command-line secrets manager. Try using them.

And if the user needs to input passphrase every time, what's the point of deriving different encryption keys? If passphrase compromised, all the keys are compromised.

it depends on the metaphor implementation -- it doesn't need to be every time. The same risk, or perhaps even greater, is when that's left in environment variables (in shell memory, history, ...).

yihuang commented 4 years ago

Install perhaps any command-line wallet, any command-line password manager, any command-line secrets manager. Try using them.

The original motivation to bring in the encryption key is because our wallet requires the user to input the spending passphrase for almost all commands, especially syncing which needs to be run regularly, it makes the passphrase very insecure. AFAIK, no other wallets do this. Do you want to bring back the UX of client-cli to require the user to input passphrase?

tomtau commented 4 years ago

Install perhaps any command-line wallet, any command-line password manager, any command-line secrets manager. Try using them.

The original motivation to bring in the encryption key is because our wallet requires the user to input the spending passphrase for almost all commands, especially syncing which needs to be run regularly, it makes the passphrase very insecure. AFAIK, no other wallets do this. Do you want to bring back the UX of client-cli to require the user to input passphrase?

The current UX of "inputting auth token" seems very unusual and causes a high astonishment among us and external partners. I have a limited experience, but every wallet I used only required me to input a passphrase -- then for a time period or a "session", some functionality is accessible without doing anything extra again (e.g. viewing some info), while others require some extra step (e.g. extra-auth with either re-entering a passphrase or biometrics for signing).

The security is a separate concern and there is no "perfect" one -- leaving a token (that's static and 1-to-1 derived from the passphrase) in a shell environment has the same consequences as inputting a passphrase, plus it opens up new ways where it can be snatched from (as, for example, the processes running on the same machine don't need extra privileges for reading it off .bash_history if one isn't careful).

What is preferable here is to have a more familiar UX -- if there are wallets or other secrets management command-line software with a similar UX to the current one, feel free to link them and we can learn what we can do better not to make it so astonishing -- some ideas here: https://github.com/crypto-com/chain/pull/1129#issuecomment-591767899 If there are none, then, yes, inputting a passphrase can be one part of a common "lock/unlock" UX metaphor (but there are more parts to be added for it).

tomtau commented 4 years ago

something similar to https://github.com/stevelr/secret-keeper/#secret-keeper can be considered -- in that way, the "lock/unlock" metaphor could be implemented by using a different backend (e.g. 1Password or Hashicorp Vault) to store the decryption token