Lunie: Password on transaction flow

Created on 25 Nov 2018  路  12Comments  路  Source: luniehq/lunie

As of user feedback we decided to not persist the password in the state. As a result we will ask the password on every transaction.

Scope:

  • [x] The transaction modals will need a new input field to enter the password.

    • Note: the password needs to be passed through to the send function

  • [x] Design the new modal signing flow #1735
  • [ ] On login the user doesn't need to enter a password #1718

    • We could just remember the last login and skip the login screen (yeah!)

design-work-needed epic high priority security split 馃崒

Most helpful comment

Different users may have different requirements. For me this would make a lot of sense, for two reasons:

  • Often I might open Voyager just to view state / check if I've received a transaction, for which I will never need my password (or Ledger).
  • When I do in fact send transactions, I want to double-check each before I send (lest I click a button by mistake) and I don't mind being prompted for my password each time (I'd rather be, since it's clearer that I'm "signing something").

I think it also helps with application security, since we no longer need to persist the password in state (so any kind of code injection wouldn't be able to copy it, although they could still display false things to the user).

All 12 comments

On login the user doesn't need to enter a password

i think we should let users choose if they want this

Different users may have different requirements. For me this would make a lot of sense, for two reasons:

  • Often I might open Voyager just to view state / check if I've received a transaction, for which I will never need my password (or Ledger).
  • When I do in fact send transactions, I want to double-check each before I send (lest I click a button by mistake) and I don't mind being prompted for my password each time (I'd rather be, since it's clearer that I'm "signing something").

I think it also helps with application security, since we no longer need to persist the password in state (so any kind of code injection wouldn't be able to copy it, although they could still display false things to the user).

thanks for the input @cwgoes! i think this makes a lot of sense and was excited to hear the idea!!

Often I might open Voyager just to view state

true, but i feel some folks might like the comfort of knowing that if someone else uses their computer or if they are on a public machine that a password will be required to view "their state"

voyager on the web will provide a hub-wide state view - but for accounts which include an account name and certain preferences over time, this could feel like an invasion of sorts. that's why i like giving the user the option (a checkbox that asks whether or not they want to enter their password to view their state)...

we no longer need to persist the password in state

yep. this sounds great.

isn't the state public anyway?

technically, yes. but "logging in as someone else" doesn't feel right. what your proposing would mean you could pick any address and use voyager as if it were your own account ... right?

you could pick any address and use voyager as if it were your own account

yeah, let's discuss today

Note: This would probably mean 2 passwords. One for the local account. One for the private key. Am I correct?

good question - we'll discuss!

  • we have one password for the private key (for signing)
  • we have no password for the settings (for logging in)
  • we auto login
  • we sign on a transaction

Often I might open Voyager just to view state / check if I've received a transaction, for which I will never need my password (or Ledger).

That's true, we can include that behaviour once we merge in the explorer as the read-only version of voyager. I'll create an issue.

On login the user doesn't need to enter a password
We could just remember the last login and skip the login screen (yeah!)

I'd change this to remember the last address for querying purposes

The last feature needs more thinking is handled in #1953

Was this page helpful?
0 / 5 - 0 ratings

Related issues

AdityaSripal picture AdityaSripal  路  4Comments

jbibla picture jbibla  路  4Comments

thebkr7 picture thebkr7  路  3Comments

faboweb picture faboweb  路  3Comments

jrmoreau picture jrmoreau  路  4Comments