How things work now
Currently the status app has one password, it does the following:
- opens the status app
- the option to save password then encrypts this password with a one-time-key and stores it in secure hardware elements of the device.
- encrypts the private keys which are stored in device memory (not secure hardware elements, yet)
- encrypts db
- confirms transactions when sending (after verifying the 3-word phishing phrase)
If we lose this password, or forget it, or it gets compromised, everything is lost/stolen/etc.
We are moving away from this
With the addition of separating the keys in the Status App, we have an additional benefit of securing each of them with separate constraints and permissions, or having passwords for various access.
By default, we should always have a secure option that is not tied to the underlying OS of the app. That being a secure, user-chosen password (not biometrics, they are not secure passwords, they are a QoL option and āauthenticationā).
So, looking at these things, letās talk about options within the app, as the addition of these things potentially adds friction in the UX/UI.
I will use this diagram (WIP) as a reference for discussion here.
Options
It might make sense to have separate security zones within the app, which each have additional QoL options for override.
Note that each secure user-chosen password
does not necessarily need to be the same
Low Security Zone
defaults to: secure user-chosen password
App Sections:
- Opening the app
Additional Override Options:
- biometrics
- 6 digit pin
- keycard tap
Medium Security Zone
defaults to: secure user-chosen password
App Sections:
- viewing wallet (āAccountā browser in diagram)
- adding watch āAccountsā
- interacting with dapps
Additional Override Options:
- biometrics
- keycard tap
High Security Zone
defaults to: secure user-chosen password
App Sections:
- confirming transaction send
Additional Override Options:
- keycard tap
Lost or lockout recovery considerations
Restoration and Backup
As of right now, if we try and restore an account, we will only restore the keys associated with the red lines in the diagram. This means we lose all respective key associations, names, etc and all of the profile settings we have stored.
Igor mentioned a possibility to create an additional Master Key from the Main master key which could be used as a top-level encryption key for everything. This encrypted blob of settings could be backed up separately, and the entirety of someoneās āStatus Accountā could potentially be restored simply from the 12-word-seed. (Note that a password would have to be re-setup)
This encryption key should be stored in the devices secure hardware element and encrypted with whatever is used to open the app. The subsequent flow would then be:
- login with Low Security Zone credentials
- retrieve and unencrypt master encryption key
- unencrypt whatever needs to be accessed.
Save password options can be used as is to keep things unlocked, but we would then have a way to back up the entirety of app using only a 12-word-seed (and some means of storing and retrieving the encrypted blob of user data stuff
Lockout
If users enable things like the 6-digit pin and biometrics, then we should also lock-out the App upon multiple failed attempts to mitigate from brute force. This can only then be restored from default user-chosen password (probably also lockout), or complete restoration from 12-word-seed.
I understand that much of this can and will cause UX/UI friction, but we have to get this right if weāre going to ship and stand behind a āsecure and private app.ā