Status passwords and what they give access to

[petty]

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.”

[rachel]

Thanks for the visuals. The diagram is great.

I’m trying to understand the impact on new user sign-up.

These are the requirements that I’m hearing:

1. We need to keep password creation in the sign-up flow. Every user needs a secure password. A 6-digit code is not secure enough to rely on alone.
2. The password is the default for unlocking the app.
3. The user can optionally set up a biometric log-in or 6-digit pin option, once onboarded.
4. He or she can opt to log in to the app using this feature instead of their password. This is simply for user convenience.
5. Within the app, the same secure password should be required to access certain security zones, such as the wallet.
6. Those access points can be over-ridden by other security options, but not disabled.

From a design perspective, it means reintroducing password setup to the onboarding flow, and moving biometric options elsewhere.

It means there are a number of options for signing into an existing account—biometric (x2) or password—depending on user’s preference.

And it means introducing several points of friction elsewhere in the app, where security clearance is required.

Based on the screens @andmironov has already worked on, it sounds like if we reintroduce password creation to sign-up, and figure out another place for optional biometric setup, we can move ahead with implementation.

The creation of security zones could be phased in later.

Questions

• What is the relationship between password and keys in a multi-account scenario? One password to rule them all?
• Is using the same password ever necessary in account recovery? If we generate another Master Key to encrypt data such as profile photo, and recover that based off the 12-word seed phrase as well, the user still sets up a password of their choosing during recovery?

[hester]

I understood earlier that it might be an option to add a password later. Do you see that as a feasible solution, in any shape or form, @petty?

Reason I ask is because we can offer a much better experience by allowing people to opt into ‘security zones’ (thanks for that language), in context and on their own terms.

For example opting to enter low security zone once you actually have assets to worry about and not when you’re looking to explore Status and merely follow a public channel.

By enforcing our low security zone from the get go, it seems to me we exclude anyone interested in private and secure messaging, but not in crypto.

There is something to say for narrowing our target group, as well as for educating people that crypto and decentralized messaging+dapps go together to ensure platform sustainability. Personally I don’t see that as the most inclusive approach to eventually get people engaged and excited about this aspect of decentralized technology.

[petty]

I personally see no problem in securing the App after creation of keys. The user has no chats, no money, or profile settings.

As long as we make sure to nudge them or force them for certain Security Zones to set proper passwords and safeguards then I’m fine, which should help with the flow of on-boarding.

For instance, when a user receives money, they should be forced to set up a password if they haven’t. They should also be told at the end of on-ramping if they skip that section to go do it asap, to safeguard their chat privacy, etc.

[rachel]

So, we simplify further @hester @andmironov?

[hester]

I’d say initially add password can be merged with the back up seedphrase flow for which we have prompts in place. Making it more a general ‘Protect your [TBD]’.

Current prompts are a badge on profile until backup and a reminder in wallet as soon as you have some assets.

Next steps could be to strengthen these prompts through in-app notifications (already on backlog) as well as updating Wallet setup and potentially merging 'Protect your [TBD] there.

Updating wallet needs to be done regardless to:

• align with latest proposal on visual representation of signing phrase
• currently anticlimactic with a process introscreen followed by a single process screen
• adapt to new terminology and multi account introduction

[gravityblast]

@petty

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)

@petty @igor with keycard we are already using an encryption key derived from the master key, do you think we can use the same?
We use a path described in EIP1581:

m / purpose' / coin_type' / subpurpose' / key_type' / key_index

We use key type 0 for chat keys and 1 for encryption keys.

We would like to use m / 43' / 60' / 1581' as a hot keys root, so we would need to store it as well so that we can derive other hot keys for chats, dapps, etc. would that be ok?

[igor]

maybe… it is just a key to encrypt the realm DB, basically user’s settings and profile

[jarradhope]

I like pincode because it unifies keycard and key encryption, one less thing to worry about.

Passwords have not been well-received by our users, and ultimately lends to creating weak passwords to avoid the friction (even our own @gravityblast used a series of 0’s when signing a tx in metatransaction demo video). One can argue that enforcing a password does not ensure the security goals we’re trying to achieve.

Biometrics on their own are not strong enough, should always be used with a pin.

For software keypairs, I don’t see pincode with some device mixins (hardware id, biometrics) to generate a password for disk encryption, or storage in secure enclave for software keypairs as an issue. It gives us a reason to upsell the user to more security, upsell to Keycard.

Additionally we are looking to enable more advanced recovery, we already have smart contracts for recovery and proxies, or we can do MofN key splitting.

I like smart contract based recovery because it de-emphasizes importance of keys, and allows them to be disposable, while MofN key splitting makes them emphasizes the key. An original intention behind asym keys in crypto was to make them disposable.

I would like to see 24 word key phrases be a thing.

[petty]

@jarradhope

(even our own @gravityblast used a series of 0’s when signing a tx in metatransaction demo video)

No one is going to use a real password in a demo video.

I’d like to know more about this pin + device mixin. Do you have anything I can read to look deeper into this. I’d like to make sure we get this right as it is literally the entry point of all security we offer.

[jarradhope]

I would argue that the behaviour happens not because it’s a demo video.
Keep in mind mobile password managers are not commonly used.

Ask Piper about his tale of using too strong of a password in Status

[petty]

I get your point, hence my optional QoL override options in the OP. Default to a secure password, allow for QoL if user wants it. It isn’t easy trying to cater to all possible people, ranging from “super secure paranoid guy” to “casual don’t-give-a-fuck-about-security guy”

[petty]

Igor is writing up a spec for your pin + device idea tomorrow, I’m going to review it then.

[kevinsimper]

I feel strongly about this because the first Status account I created I lost access to because I forgot the password, because I felt it needed to be more secure than other passwords and therefore I forgot it

It would even be cool if you could start in “Rinkeby mode” where things was in lesser security and you could upgrade to mainnet when you are finished playing.

I teach Ethereum workshops and it is defenitely more difficult to get them to use a mobile wallet than their desktop wallet with Metamask, where Rinkeby is just 1-click away.

[jarradhope]

I think we’re already thinking about differing security when the user is more invested.
It might be worth seeing how we can be more creative in how we increase security of a user over time/increase in funds under management.

I feel like we can simultaneously reduce barrier to entry, educate user and continue to increase their security as the user matures.

For example, if we’re supporting multi-accounts and transaction rules then we can have rules that automatically move funds out of hot accounts into cold accounts.

The persona that cares about security will go through more hurdles thats for sure. So if we support a password that can be set after. Or we defer them to BYO key/account (and we provide tooling and recommendations to do that on airgapped machine), in which tx signing happens over QR code only?