search

trezor / trezor-firmware

:lock: Trezor Firmware Monorepo
https://trezor.io
Other
1.35k stars 654 forks source link

confirmation dialog before PIN unlock #1376

Open matejcik opened 3 years ago

matejcik commented 3 years ago

When Trezor is softlocked, in some cases it makes sense to show confirmation first and only ask for PIN afterwards.

In particular, SSH authorization (SignIdentity) and FIDO authorization would benefit from this.

Same could be done for settings. In particular, we could cheat our way through "change pin" problem by first asking, and then the user would not need to enter current PIN twice.

UX-wise, we would need to show "Unlock" button instead of "Confirm" button for this to be nice.

Implementation-wise, we would need to make the handlers "softlock-aware". Presumably there is a small number of messages for which this makes sense, so we could just allow them through and put the logic in the handler itself. FIDO already has custom softlock handling, so presumably this change would not be so huge?

andrewkozlik commented 3 years ago

This is also related to:

  1. Change PIN
  2. Change wipe code
  3. Enable/Disable SD protect
  4. U2F/FIDO2 operations with non-resident credentials
  5. FIDO2 operations with resident credentials
  6. Dry run recovery

In cases 1, 2 and 3 the PIN is needed (cryptographically) to perform the operation and PIN entry is a part of the workflow (probably the second screen).

In cases 4, 5 and 6 the storage needs to be unlocked to perform the operation. In case 6 PIN entry is always required, but only for user verification (cryptographically we could do without it once the storage is unlocked). The same applies to cases 4 and 5, where user verification may be requested by the remote party. In this case the PIN entry dialog is shown after the user confirms their intent to log in. For resident credentials (case 5) we need to access data in the storage, whereas for non-resident (case 4) we don't. For both resident and non-resident we need access to the corresponding BIP32 node in order to be able to recognize the credential and decode it to get the user name in FIDO2. The only difference between cases 4 and 5 is that we could cache the node easily, whereas caching the credentials in the storage would be way more complicated.

This topic has already been discussed here: https://github.com/trezor/trezor-firmware/issues/1148#issuecomment-665095751 https://github.com/trezor/trezor-firmware/issues/949#issuecomment-615135412

matejcik commented 3 years ago

wrt non-FIDO usecases, the solution the UX problem is possible even without pre-loading the confirmation:

  1. explicitly ask for PIN in the handler
  2. ask for confirmation in the handler
  3. perform unlock with the cached PIN after confirmation is given

this process might be applicable elsewhere, in particular in case (4) above. In case (5), a different screen than "Verifying PIN" would be nice, at least something like "decoding credentials", but even better, some sort of screen that implies "please keep waiting with Trezor in your hand"