Cosmos-sdk: UI related: How should the sign in flow look like?

Created on 24 Jan 2018  路  12Comments  路  Source: cosmos/cosmos-sdk

How do we want the process of signing and sending tx be. Is the focus on security or usability?

Quoting @nylira:

If I'm getting this right, Jae is proposing that we release Cosmos UI as two binaries, an online one to view and create transactions -- CosmosUI, and an offline to hold keys and sign transactions -- CKeystore. This means to send coins, the user will have to:

Create the transaction in CosmosUI
Export the transaction to a USB drive
Get access to their offline computer
Insert the USB drive with the transaction data into the offline computer
Import the transaction data into CKeystore
Sign the transaction with their private key
Export the signed transaction to the USB drive
Get access to their online computer
Insert the USB drive with the signed transaction into the online computer
Import the signed transaction into CosmosUI
Confirm sending the transaction
If that is the primary send flow for users, I think a lot of people are going to be turned off from using Cosmos due to the time investment and complexity. I understand the security advantages. But --
using physical media to transport data between computers is archaic.

What if they don't have another offline computer? Most people only have a laptop and a phone, both of which are internet connected.
Discourages end-users interested in testing the app with a few tokens they earned from a faucet
If they only have five bucks in the UI, they don't need this level of security
This will increase the complexity of implementing an automated buy/payment feature (let's say someone wants to implement Netflix on Cosmos)
Other major cryptos don't require this, and the average person will see this UX as a step backwards compared to the ease of entering in a password to Electrum/MetaMask and instantly sending funds.
Ledger provides better UX, but those are out of stock until March 26th (https://www.ledgerwallet.com/products/ledger-nano-s), which means user acquisition is going to be very slow.
Here are my ideas:

Drop the extra security requirement with the two binaries and just allow password-verified sending. Requiring either the two binary flow or a ledger is going to throttle our user acquisition to hardcore believers. We can create a warning in the app about how users should really get a hardware wallet.

Work with Ledger or some other hardware company to develop a Cosmos-branded HSM that we can sell for a token amount -- let's say $10, or we hand out for free at conventions, etc. This HSM needs to have some ATOMs preloaded on it so users are excited to purchase and set up this device. It's okay to sell this at a loss to increase our user base.

A lot of companies are using an in-between level of security with the requirement of a code from Google Authenticator/Authy. Could we use something like this as a stop-gap between fully offline secondary computer and fully-online password-only verification? Most people are familiar with using these apps already, and almost all of them will have phones.

Most helpful comment

The advanced multi-computer setup will be important, but only for a certain class of people (the whales). There will be people using our tools to handle crazy large amounts of money, so for them extra UX barriers aren't an issue since they want to keep their atoms safe.

But this doesn't have to be a launch feature, these people are probably fine with using the CLI to do the advanced flow so for the UI we can focus on regular small-time users.

All 12 comments

Or we could have the secure mode (UI + KS) as an option on login page?

Currently we have:

  • Sign in with password
  • Sign in with seed
  • Sign in with ledger

We would add a fourth option:

  • Sign in with public key (or address)

The first three option require to have the private key, but not the fourth. Fourth option allows to use the UI with any public key. The difference with this option is that when you click on a button to perform an action (i.e. sign and send a tx) instead of fetching the privkey and signing, the UI displays the unsigned tx associated with the public key that was entered.
Then, the user can take this unsigned tx and sign it with Cosmos KS if it indeed possesses the privkey.

This would require to add a section on the UI "Relay Transaction" where you just input a signed tx and type send.

This way you get the best of both worlds.

I like the proposal by @gamarin2. I would pre-fill the address, with the last address used. This generates a one click sign in. What do you guys think @cosmos/cosmos-ui ?

i would prefer to keep our conventional authorization model in place. what is gained from a 1 click sign in is lost by unusual UX and added technical complexity. i don't understand the advantages of letting people sign in without private keys. why do we want people to be able to do this?

How do we want the process of signing and sending tx be

do we have to change anything? what is the problem with how it works now?

2fa would be a good idea. but i'd advocate for using it on sign in, not for signing tx's.

i don't understand the advantages of letting people sign in without private keys. why do we want people to be able to do this?

It allows you to keep your private keys on an offline computer for added security. The offline computer would only have Cosmos signer on it.
Admittedly it will not be used by most users but it would be useful for large holders.

ok i see! if a user signs in with a ledger nano, i don't see why the hardware can't sign tx's for them.

Currently you always have to type in your password when you want to enter the UI. For me as a developer this is already annoying. I could imagine, that it is as well for users. Not feeling stronly for this feature though.

ok i see! if a user signs in with a ledger nano, i don't see why the hardware can't sign tx's for them.

I still believe it's a cool way of letting users choose their security setup. Not everyone wants to buy Ledger wallets and who knows maybe they'll get compromised in the future.

@faboweb

Currently you always have to type in your password when you want to enter the UI.

the other side of this is that it feels secure and is an expected / normal auth flow. i also don't feel strongly about our decision here. what i care strongly about is limiting complexity and resources required before launch 馃憤 馃殌

@gamarin2

I still believe it's a cool way of letting users choose their security setup.

we do let them choose. at present, we intend to offer users 1 way to use the UI without storing their private key on their computer. i think this is sufficient for now.

i think we have to draw the line somewhere (i don't know where - so this a good conversation to have). this is open source software. if our security offering is unsatisfactory for a minority of users, they can fork the UI and do whatever they please. or they can interact with the CLI directly.


in my mind the UI says, "hey most people! here is an easy way to interact with the cosmos hub".

The advanced multi-computer setup will be important, but only for a certain class of people (the whales). There will be people using our tools to handle crazy large amounts of money, so for them extra UX barriers aren't an issue since they want to keep their atoms safe.

But this doesn't have to be a launch feature, these people are probably fine with using the CLI to do the advanced flow so for the UI we can focus on regular small-time users.

how does this thread effect the SDK?

The modifications currently discussed here so not effect the SDK as it already has the option to sign a generated TX.

The question for the SDK was: Should the SDK provide a way to build + sign + send a TX in one step providing the locally stored account name and password.

As it would be hard for future contributors to this thread to get this core question, I propose:

  • renaming this issue
  • closing this issue
  • creating a new issue in the cosmos-ui repo targeting sign-in possibilities so we have the information in one place
  • creating a new issue regarding one step TX sending in this repo

I offer to do all this, if I get the go ahead by one more person.

Good conversation to have but let's move this to the UI repo and once we're clear on what we want from the UI sign-in flow we'll see if we need to open new issues to support it in SDK

@faboweb to do the honours :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jackzampolin picture jackzampolin  路  3Comments

hendrikhofstadt picture hendrikhofstadt  路  3Comments

rigelrozanski picture rigelrozanski  路  3Comments

rigelrozanski picture rigelrozanski  路  3Comments

ValarDragon picture ValarDragon  路  3Comments