Allow users to change their password

[hesterbruikman]

Feature Issue

When users first use Status they are asked to create a password. At this point they might not see enough value in Status to create a secure password. Users should be able to upgrade their password.

User Story

As a user I want to change my password because I used a simple password and want to create a better one.

Description

• Designs on Figma
• This feature should be available to regular multiaccounts

Acceptance Criteria

Implementation follows designs

Notes

Designs were created Oct 2019. Please ping @hesterbruikman when starting to discuss feasibility and if any update is needed

[hesterbruikman]

cc @andremedeiros @0kok0

[rajeevgopalakrishna]

The related user story is when user forgets/loses password and wants to reset it.

Currently, this password is also used to encrypt the chat database (DB) and so password change will require a re-encryption of DBs which we currently do not support. In the forgotten/lost password scenario, this is not even possible and a recovery with seed phrase will only recover wallet assets but chat history is lost.

In the Keycard scenario, the chat database is encrypted with a key derived from the key pair at m/43’/60’/1581’/1/0 because there is no password with Keycard.

In the non-Keycard scenario, if we encrypt the chat DB with a key derived from the key pair at m/43’/60’/1581’/1/0 and only use the password to encrypt this chat DB key, then changing of password will not require a re-encryption of DBs. This will also allow chat history to be recovered using the seed phrase in the forgotten/lost password scenario.

Also, this approach will make Keycard and non-Keycard scenarios consistent w.r.t. chat encryption and recovery.

cc @cammellos @status-im/security-internal

[0kok0]

Sorry @hesterbruikman, I somehow missed the @ here.

Let me know if I'm summarizing this correctly;

• derive chat db key deterministically from m/43’/60’/1581’/1/0
• encrypt chat db key with passphrase

Case 1: Passphrase change: decrypt and re-encrypt chat db key with new passphrase. Works as plaintext chat db key can be decrypted with passphrase.

This flow/user story we can support with the keys as they are.

Case 2: Passphrase unknown/lost:

• Recover m/43’/60’/1581’/1/0 with seed phrase
• derive chat db key again deterministically from m/43’/60’/1581’/1/0

We would shift the security of the model fully to the security of the seed phrase/private key. From what I understand the idea was here to capsule the different components, e.g. chat/wallet, so if the seed phrase is compromised, the chat key/history is not.

[rajeevgopalakrishna]

Accurate summary. And good point about the separation of chat & wallet security with passphrase and seed phrase.

But with Keycard, there is no passphrase anymore and so the security of both chat & wallet rely only on the seed phrase. So with this reasoning, it sounds like security isolation downgrades with Keycard.

cc @guylouis

[guylouis]

About this "what I understand the idea was here to capsule the different components, e.g. chat/wallet, so if the seed phrase is compromised, the chat key/history is not" I have a naive question: is that really a goal we have ?

I also understood in the past that we had planned to have in the long run some mechanisms to recover your full status experience (including chats) from a recovery of your seed phrase only. Please see this (old) thread : https://discuss.status.im/t/status-passwords-and-what-they-give-access-to/1195

[hesterbruikman]

About this "what I understand the idea was here to capsule the different components, e.g. chat/wallet, so if the seed phrase is compromised, the chat key/history is not" I have a naive question: is that really a goal we have ?

Same question, sounds like a sensible goal, but I don't recall this as one we committed to. Doesn't mean it didn't happen, just that it might not be widely known or documented. I'd be hesitant to make changes without having this confirmed by Corey when he's back.

In the meantime, maybe @yenda or @rasom can speak to whether there is a reason to not use a deterministic key to encrypt the chat db and whether this has been discussed before.

I think we'd also need to consider what happens if the chat db is synced to desktop. 🤞 the answer is, it's not relevant, but I think impact on other clients needs to be explicit in any specs

fyi @johnlea-quiup

[cammellos]

I think we'd also need to consider what happens if the chat db is synced to desktop.

It is not relevant, correct, syncing happens through the wire and not through sharing db etc

[cammellos]

Also we discussed this before, but I can't find the conversation, it might have been on discord etc, @yenda or @rasom might remember

[3esmit]

More people requesting it

[hesterbruikman]

cc @shivekkurhana