Account recovery analysis

[rdevries-thoughtworks]

As a follow-up to #754, we need to understand how we can technically implement this, and more in particular how we can interface with the LEAP approach to account recovery.

[elijh]

@rdevries-thoughtworks, my proposal is to allow two types of password reset:

1. Account reset: allow a user or admin to reset the password, but doing so also entirely resets the account, erasing all the stored email and keys.
2. Account recovery: allow the user to change the password, and keep all their data, if they provide a password change token.

For (1), this just needs to be added to leap_web. For (2), this just needs to be added to the Soledad client API. I don't think there is anything for pixelated to do other than either wait for leap_web changes or go ahead and make the change yourself.

[elijh]

It makes sense to start with Account Reset, because that is easy and should be easy to implement now in leap_web.

[SweetVirginia]

@rdevries-thoughtworks

Bellow the mockups we'll prototype to test with our users: https://invis.io/ZR8W9K1DA

Soon I'll add some more blueprints.

[rdevries-thoughtworks]

@SweetVirginia tx. We have a few questions:

• what happens if the user e.g. closes the browser before he enters the recovery email address? Is the account created (and usable) then? If so, will he be able to add the recovery email some time later?
• is it the default that the recovery email address will be asked after entering the new password? Or is the existing recovery email prefilled?

[SweetVirginia]

what happens if the user e.g. closes the browser before he enters the recovery email address? Is the account created (and usable) then? If so, will he be able to add the recovery email some time lat

Good question, I haven't started working on corner cases yet. Do you have ideas? I was thinking to have a "settings" tab at Pixelated User Agent UI, there users could change their passwords and add/change backup accounts.

is it the default that the recovery email address will be asked after entering the new password? Or is the existing recovery email prefilled?

It could come prefilled. Less work, right? :)

[rdevries-thoughtworks]

Do you have ideas?

I think it might be a good idea not to create the account until there is a backup account, because otherwise people might skip the step without understanding what they're doing. Changing/adding recovery accounts in the settings could be a nice addition to this, but deleting all backup accounts should probably not be possible. All depending on whether or not we want to give the users a foot gun.

[rdevries-thoughtworks]

@SweetVirginia Do we want a confirmation link in the backup email inbox mail, which has to be clicked to activate the user account? If not, the user might e.g. have mistyped the backup email address, and will still be able to shoot himself in the foot.

[SweetVirginia]

@rdevries-thoughtworks Yes. :walking_woman: 🔫

[rdevries-thoughtworks]

See the opening move on this from LEAP side here: https://lists.riseup.net/www/arc/leap-discuss/2016-10/msg00001.html

[olabini]

I think we should discuss the idea of the confirmation link. I'm not a 100% sure it makes sense.

[rdevries-thoughtworks]

Current understanding of how LEAP will implement account recovery: A logged in user can at any moment request a recovery code, also when one had been requested before. Whether there can be more than 1 recovery code at a time is not yet clear to me.

Pixelated could make use of this functionality by requesting the recovery code through the LEAP API, and then split it through ssss. Splitting would happen in a few steps:

1. the LEAP recovery code would be split into a user part (sent to the backup email account) and an admin part, where both parts are needed to get the LEAP recovery code
2. since there can be multiple admins, the admin part would be split into a part for every admin, where any admin would be able to reconstruct the shared admin part

The ssss commandline utility doesn't support the second step, because it doesn't support a threshold of 1. Whether that is a limitation of the scheme or of the application is not yet clear to me. According to wikipedia, secret sharing with a threshold of 1 is trivial, so that might be a reason that it's not implemented. If it's a limitation of the scheme, we could maybe work around it by introducing a 'public' extra part, and raising the threshold to 2.

After discussing with @olabini, we came to the conclusion that the trivial form of secret sharing -- all admins having the exact same key -- doesn't suffice for Pixelated, for a few reasons (I hope I describe them correctly here) (I think I missing 1 more reason here):

• if the exact same key is sent encrypted to multiple admins, having access to all of these encrypted messages might make it easier for attackers to derive that key by correlating the messages
• in the future we might want to support other ways of sharing, such as where 2 admins and the user have to combine their parts to recover the account; it would be hard/impossible to incrementally add that

[rdevries-thoughtworks]

@olabini regarding the confirmation link: can you explain exactly what doesn't make sense? Do you think it doesn't reduce the chance that users never receive their recovery code? Or doesn't it add enough to make the signup process so cumbersome?

[rdevries-thoughtworks]

I see a potential problem in the recovery workflow:

I'm assuming recovery codes are for one-time use only. Then when you enter your new password, the old recovery code is invalidated, and no new one is created yet. But unlike the signup workflow, the account can't (or can it?) become inactive until the recovery code was created and sent to the backup email account, or maybe even until the user has clicked a confirmation link.

We could put the new password field and the backup email account field on 1 page, then the recovery code can be created and sent. This won't solve the problem completely if we want to use a confirmation link.

Alternatively, we could have some alert in the Pixelated UI to tell the user that the current recovery code is not yet created/confirmed, or that no backup email account is configured.

[rdevries-thoughtworks]

After discussing with @shyba, my current understanding of the LEAP user registration and password change workflows is as follows:

• Users register against the LEAP web app (RoR), which in turn creates some document in a database in CouchDB
• On first login, Soledad verifies the user against this database, and creates an AES key for the user, stores it in the recovery_document, and creates the user's personal database
• Password changes are done through Soledad, not the web app; this is actually used now in bitmask
• Logging in through the LEAP web app will be removed, if I understand correctly

[rdevries-thoughtworks]

If we want to create a recovery code during signup, then we have a technical mismatch with the current way of creating recovery codes. The secret is currently only created on first login, but it's already needed (for encryption with the recovery code) on user registration. So probably we'll have to pull the whole SoledadSecrets.bootstraping to the signup phase.

[olabini]

When it comes to the confirmation email, the problem I have with it is that first, it is hard for me to see how to do it without unpleasant security problems (where the server has to keep the key material), second, what about the sysadmin? Should they also confirm? And what happens if we add more ways of doing recovery/trusted contacts? Should we force a recovery code etc? In that case as you mention, it stops the signup flow.

[rdevries-thoughtworks]

@olabini

how to do it without unpleasant security problems (where the server has to keep the key material)

We would encrypt the secret with the recovery code, and send an email with both the recovery code and the confirmation link to the backup-account. The confirmation link would activate the account without needing to do anything with the recovery code. Do you see problems with that approach?

what about the sysadmin? Should they also confirm?

The sysadmin address(es) don't depend on user input, so are less likely to go wrong. I don't think confirmation mails are needed for that.

And what happens if we add more ways of doing recovery/trusted contacts?

If e.g. you need the recovery codes of 3 out of 6 trusted contacts, then the risk of too many of them not having theirs is not too big. But we could also choose that at least three would have to confirm, or all of them. It's a bit of a pain, I understand, but also if you loose your recovery account, that can be a very big pain. It's a trade-off.

It also could make sense to treat the backup-account of the user herself different from trusted contacts, and only require confirmation of that account.

We can also make this configurable, either per-installation or per-user.

Should we force a recovery code etc?

I thought that was the idea, yes.

In that case as you mention, it stops the signup flow.

Yes, indeed. It's not ideal, but this is what many other applications do too. Admittedly, more and more applications don't do this, and that's a really nice experience, but it's a trade-off. We'll keep this in the back of our minds, and hope something nicer comes up.

[rdevries-thoughtworks]

Regarding reset account:

This is different from deleting an account and recreating it. Deleting an account would 1) allow an attacker to claim the account, and 2) remove any security insensitive information about the account unnecessarily (some user settings).

After discussing with @SweetVirginia, we came to #798. Note that technically, the reset code is very similar (equal?) to a one-time password.

[azul]

Just read up on all of this. First of all i really like the mockups and the workflow. :sparkles: I can confirm what you wrote about the leap approaches so far.

I'm not quite clear what the threat is you are trying to protect against? Does it include local jurisdiction and search warrants? In most jurisdictions law enforcement can search the content of mailboxes. This most likely includes the mailbox the recovery code was send to. With that code the pixelated provider could be enabled and possibly forced to hand out the user data.

I guess there's two ways of shooting yourself in the foot here. Having no access and having too much access to the data. Just trying to make sure the latter is not the case.

[azul]

After discussing with @olabini, we came to the conclusion that the trivial form of secret sharing -- all admins having the exact same key -- doesn't suffice for Pixelated, for a few reasons (I hope I describe them correctly here) (I think I missing 1 more reason here):

• if the exact same key is sent encrypted to multiple admins, having access to all of these encrypted messages might make it easier for attackers to derive that key by correlating the messages

What kind of encryption are you thinking about? My first shot would be sending an pgp encrypted email to the admins. Do multiple recipients of the same message weaken the security of pgp?

in the future we might want to support other ways of sharing, such as where 2 admins and the user have to combine their parts to recover the account; it would be hard/impossible to incrementally add that

What is the problem here? Is it migrating the code or the fact that the admins already have a recovery code that allows them to recover the account with the user alone? The latter seems to be intrinsic to the problem of locking out combinations that had access in the past. So either way a new recovery code would have to be generated. I would be curious why adding ssss then would be so hard.

[rdevries-thoughtworks]

What kind of encryption are you thinking about? My first shot would be sending an pgp encrypted email to the admins. Do multiple recipients of the same message weaken the security of pgp?

I'll leave this to @olabini

What is the problem here? Is it migrating the code or ...

Yes, it's migrating the code.

[rdevries-thoughtworks]

I'm not quite clear what the threat is you are trying to protect against?

Users might not secure their backup account so well, so if that gets hacked and the recovery code is in there, the Pixelated account is compromised too. By splitting the recovery code, the attacker would also need to get to (one of) the admin account(s), who we hope will have protected his account more thoroughly.

[elijh]

Users register against the LEAP web app (RoR), which in turn creates some document in a database in CouchDB

Technically accurate, but conceptually user registration is handled by the Bonafide API, which does currently happen to be part of the web app process, but will not in the future.

Password changes are done through Soledad, not the web app; this is actually used now in bitmask Logging in through the LEAP web app will be removed, if I understand correctly

Well, all authentication must happen through the Bonafide API, which is still technically part of the web application, but will get factored out. There is no plan to remove authentication from the web application, since you might need to login to check tickets or modify billing information. There is a plan to allow for automatic authentication if the webapp is opened with an active session token, to allow the client to open the webapp directly without the need to supply the password a second time.

[rdevries-thoughtworks]

@elijh So the Soledad server will implement the complete server-side Bonafide API, and the web app will provide an HTML interface to that?

There is a plan to allow for automatic authentication if the webapp is opened with an active session token

Single sign-on?

[elijh]

The plan is is to make the Bonafide API a stand alone thing. The API would be consumed by Soledad Server, Soledad Client, the webapp, pixelated ua, and bitmask --- anything that needed to authenticate, sign up, log off, verify active session, change password, or get a certificate.

Here is the API definition https://leap.se/bonafide

[rdevries-thoughtworks]

Password change is required to do account recovery, but currently this is broken for LEAP/bitmask. This is due to the client bonafide code. Password change should change the login-password (actually only the verifier), which is owned by the webapp, and the soledad password. But currently only the soledad password is changed.

Even if both passwords would be changed, because this can't be done atomically, there is a risk of the passwords ending up out of sync. To circumvent this, it would be possible to first add the new password to soledad, then change it in the LEAP webapp, and then remove the old password from soledad.

[tayanefernandes]

I put the videos and a document with users feedback in this folder: https://drive.google.com/drive/folders/0B9eV_QvJTOVRNmpZQnBVelo3dTA?usp=sharing

[rdevries-thoughtworks]

I've created issues #801, #802, #803, #804, #806, #807, #808 for implementation of account recovery. This issue is not done, though, before we know how to do account recovery with Bonafide.

[olabini]

OK, sorry for taking some time responding to this. When it comes to stopping the signup flow for the confirmation, I think I'm against that - weakly. It seems like the cost of losing the account keys directly after signing up is not such a big deal compared with losing it later. We could also do things like "nagging wizards", when you login sometimes it will remind you to add a recovery code.

[olabini]

About resetting password, you are right - it would be great to do that using a one time code of some kind that allows for a person to keep control without any risk of timing attacks. It is more complexity though, so maybe having a simpler solution first is ok.

[olabini]

When it comes to Azul's question of threats we are trying to protect against: Primarily, we want to avoid the provider having all the information necessary for recovering an account. In theory a government can access mailboxes all over the place, but the more we do this, the harder that will be - especially once enough people have encrypted email so that the recovery codes can be sent encrypted to both the sysadmin and the recovery account. At that point access to the machines doesn't help.

[rdevries-thoughtworks]

About resetting password, [...] so maybe having a simpler solution first is ok

For example the admin being able to remove a user completely?

[rdevries-thoughtworks]

Regarding account recovery in Bonafide: this is not implemented yet. On first sight, a similar approach to how it's handled in Soledad seems a viable option. LEAP will discuss it shortly and come back to us.

[zariye]

Thanks to @tayanefernandes I am just reading the user feedback, and want to document what I do read from there (I do not want to bring any opinion on it, bc I know they are not super secure as well, but maybe they also can be combined with something else):

1. secure questions
2. recovery code send to the cell phone

[SweetVirginia]

@zariye something like 2-factor-auth-like would be awesome. But we have to analyse how safe is that, and its cost - in developing time and money - SMS and stuff like that cost money and lock you out if you are out of the country. Also, rely on cell phones sounds for me that we will rely in another communication channel we don't trust.

I think it makes more sense to look at this from a alternative/recovery account standpoint, which is the most common on the web. Also, 2 factor auth is not as commonly adopted as we imagine :(
The main reason we are relying on the sysadmin is to have an extra layer from a service we trust (our own), otherwise, a simple backup code in your email or a picture of the codes screen in your cell phone and uploaded to your Google Drive or Apple's iCloud would be fine.

I strongly believe we can iterate this with something better for the future, but for now, this seems to be the quickest we could find out in the matters of the trade-off between security and usability. The great challenge is to make this as painless as possible. From the tests we could observe that reaching out the sysadmin is annoying (obviously), therefore is where we must concentrate better our efforts do help out our users.

About secure questions, it was one of the first ideas we had, but it's not secure at all and rely on data we shouldn't collect. :\

[SweetVirginia]

Small additional info on 2factor - it only works when the server can recover the account - which means it can't work for our model. 😞 We can try something 2 factor like for the user, but not properly.

[rdevries-thoughtworks]

@olabini I forgot to reference you in this comment; what do you think?

[rdevries-thoughtworks]

Regarding Bonafide (WIP): we could add the recovery code as a second sort-of password. This recovery code (actually: the verifier) would be stored in the users db table. We would need an API workflow similar to logging in, but different in that at some stage the new password has to be supplied.

Edge case:

• if the final password setting API call doesn't respond, it's not clear whether it came through; for this case, the client should be able to check whether the old or the new password is now valid / whether the recovery code has been used

Alternatives:

• the recovery code could be a generated code (like the soledad secret) or e.g. the scrypt hash of the password
• the recovery code could be SRP'ed like the password, or maybe simply scrypt-hashed if replay attacks are no concern
• along with the new password, maybe also a new recovery code has to be sent

[rdevries-thoughtworks]

Regarding the edge case in the previous comment:

If the final password setting API call doesn't respond, it can be re-requested. If it came through in the first attempt, this will fail with some specific response, and the client can authenticate with the new password to start a session. If it didn't come through in the first attempt, this second attempt should succeed, and creates a session in one go.

[rdevries-thoughtworks]

Regarding the alternatives in the previous comment:

• the advantage of the recovery code being the scrypt hash of the password would go hand in hand with sending the password scrypted, and then the same API flow could be reused for verifying. Since the API flow of password recovery won't be the same as authentication anyway (the last SRP request also sends along the new password verifier), this doesn't seem to add any benefit. So the code will be a random generated one.
• to stay as close to authentication flow as possible, we'll use SRP for recovery code checking.
• for LEAP it doesn't make sense to send a new recovery code along with the password, because it's not required. If the client (e.g. pix-ua) decides it wants to set a new one, it will have to set the recovery code in a new request to the 'update user record' endpoint. In order to not have to send the password verifier again when setting the recovery code, an HTTP PATCH method should be used to add the recovery code.

[rdevries-thoughtworks]

To not overcomplicate the case where the password change in Bonafide breaks somewhere along the request-response cycle, LEAP wants to leave the recovery code usable after the password change. It is the Bonafide client's responsibility (Pixelated's, that is) to remove/refresh the recovery code afterwards.

[re-nobre]

We create this document with some diagrams to help the understanding of this topic.