Lost password reset

[SweetVirginia]

TL;DR

Possibilities:

1) Backup Codes: at sign up people get a few backup codes to download. In case they lose their password they can use it. The problem with this is if people lose their password, it does seems likely to lose the backup codes too. Furthermost, people tend to take pictures of the codes with their phones which can be a harmful workaround.

2) Trusted Contacts: at sign up people inputs 3 or 5 email accounts from people they trust. Codes are sent to those inboxes. In case of lost password, those codes will be used to recover account. In informal paper prototypes and conversations with people, I observed that the first "trusted contact" people put was their own personal email (gmail/yahoo etc.). So it is a workaround that takes people to the normal interaction paradigm: backup accounts.

3) Sysadmin as a Trusted Contact: at sign up people input a backup email account of their preference and use their sysadmin as a trusted contact. In case of lost password, they'll use the code sent to their inbox and a code provided by the sysadmin. This approach is not fool proof, neither perfect but from a usability standpoint looks less painful. The proposal does NOT allow a user to just use their google account to recover the Pixelated account - that would reduce the security to the security of the google account. Instead, by requiring a sysadmin AND the secondary account, we get better security, with decent usability.

Now, for some threat models that's OK - but for some it isn't. That's also where the idea of having different policies around account recovery makes sense. Different installations will have different needs. You can always guarantee that the sysadmin has encrypted email. And then it's just a matter of setting the parameters correctly. For almost everyone, the threat will not be someone that can break into gmail AND convince the sysadmin of a small pixelated instance to give up the recovery code. And for the places where this really is a realistic threat model, you can tweak it - require more trusted contacts from different providers, etc.

From @SweetVirginia on July 6, 2016 20:7

Lost passwords

People need a way to recover their account, in a secure way. Not necessarily their emails, but that would be nice.

The current spec, that isn't fully exposed, is two passwds: 1. you pick; 2. machine generated difficult passwd ('recovery code') that you would print out and write it down. This would be all you need to restore things, and this would be required for introducing a new device. If you have a new laptop you would just put in the recovery password, and all the keys and mails would then be syncd. <--- this is partially implemented, its not exposed in the UI, and we haven't tested it.

Possibility of having three options exposed to user: 1. if i lose my passwd, allow the provider to reset passwd, generate new key for me, I lose emails, but I can get back in my account; 2. give the provider a copy of my passwd, to allow them to reset it (most convenient, lowest security); 3. shamir's secret sharing - designate three people to have a slice of your recovery document, so when 2 out of three, or 4 out of 5 or whatever, can go through the UI and do 'recover password for user X' it would then spit out a recovery code that could then be given to the user to get back into their account and re-create everything. This one would be a little tricky for UI/UX.

We would like the recovery piece exposed in bitmask, this is an important part for pixelated.

We need to ensure that the user's expectation is actually what is going to happen. People are expecting to be able to enter an alternative email address to get a password reset link, but we need to communicate that this isn't the default, and make that obvious. It might not make sense to expose all the different options. Probably start with the most simple solution and then go from there.

Security wise: would like to not be able to brute for the recovery. Would like to take recovery code, run a key derivation function on it and then send it to the server who then allows you to then decrypt the secret container (discussion of the details happened here).

TODO: work on the UX for password reset options.

Copied from original issue: pixelated/project-issues#318

[SweetVirginia]

• [x] Research
• [x] Work on workflows
• [x] Rough Sketch to start discussion

[SweetVirginia]

@cz8s about your email, I'll reply here so others can discuss too :)

Two-factor-auth relies on other devices and I don't know how much we can count on that. Which made me think that's why we don't use a backup email account account like gmail does.

Before I didn't think it was a good idea to have trusted contacts to help authenticate, but thinking on how people tend to workaround tasks, maybe having trusted contacts to help authenticate our forgetful person is a plausible solution.

That's because I researched some patterns for passwords and there were some issues with, yeah, humans... Such as:

• When people have to write down/print a code, some might just take a picture with their phones and spoil all security.
• When asked to create complex passwords (with symbols etc.) instead of long passwords (passphrases), generally people create an easy to crack complex password.

The journalists that will use Pixelated next month are super non-tech people super creatives on working around tech to make their work easier and faster and our security/experience trade-off has to be well balanced to avoid such workarounds or punishing the them hardly like resetting their account with no access to previous emails.

What worries me is that our users are different from LEAP users and making the sign-up/account settings/security experience apart from Pixelated user agent using the same experience design pattern for both seems not a good idea. What would be the cost to bring that into Pix UI?

Correct me if I'm wrong, I see that the major challenge here is to authenticate an user with less permission and data as possible (no sysadm interaction, no other accounts or personal information) and offer an user experience as "normal" as it can be (forgot my password -> click here -> create a new password).

Below (disclaimer: those are not screens, please!) Rough rapid sketches, simple flows and ideas for us to discuss on:

1.pdf

2.pdf 3.pdf 4.pdf 5.pdf 6.pdf

PS: What I meant with "password recovery" is the process of recovering access to your account, not recovering your old password :) I didn't use technical correct term, I'm sorry.
PS2: I understand the best is people use password managers, but unfortunately that's does not reflect reality yet and we have to deal with it the best we can :(

[SweetVirginia]

From @cz8s on July 12, 2016 9:41

Hi,

when I said we should look at two factor authentication (2fa) handles this, I meant that 2fa has the same problems. I didn't want to say we should use two factor. If a github user enables 2fa for their account and then loses the 2nd factor, they can not login anymore. And password reset does not work because you need you 2nd factor for password reset. This is the same problem we have.

The problem with trusted contacts is, that we need to keep a list of persons which the account owner trusts. This might be information we do not want to know about. The other problem is that the list of people a user trusts might change. And I might not remember to update the list inside my pixelated account. It would be bad if I lost my password an my old employer has to help me to recover it. It also might happen that the email address of the person I trust changes and I don't realize. If I want to recover my account and all emails to the trusted persons are undeliverable, I can not recover my account.

[SweetVirginia]

Thanks for clarifying @cz8s 😃

There were similar observations about the approaches on the images too, I'll paste them here with yours so all the issues to organise in the same comment:

Problems and user’s workarounds with Trusted Contacts approach:

• Picking up a contact who’s email account may not exist when needed (ex: fired coworker) - It would be bad if I lost my password an my old employer has to help me to recover it. is there a way (or problem with) to warn the user some account has been deleted and ask to select another trusted contact?
• The list of people a user trusts might change. And I might not remember to update the list inside my pixelated account. It also might happen that the email address of the person I trust changes and I don't realize. (can pix remember? Like Okta tells you to change your password every three months?)
• If I want to recover my account and all emails to the trusted persons are undeliverable, I can not recover my account.
• The user may use his/hers own gmail account as a trusted contact (it has the same security issue that is having a backup email account, which is super easy and expected. So, if the user will workaround on that, is it really necessary not to use the default approach?)

Problems and user's workarounds with this Backup Code approach:

• The user taking a photo of the code with his/hers phone.
• User sending the codes to him/herself other email account (gmail, etc) - given that, then why not having the option of a backup email account?
• User losing or not saving any code, writing in any random piece of paper compromising his/hers account security and access.

What I hope with this discussion: list most problems for each approach for us to have in mind while picking a plausible solution as well designing it. It only makes sense having a different approach if the solution is actually more secure, not one more security step for users workaround putting their data safety in a higher risk. There are plenty mental models that can help with that, but if it was simple we wouldn't be debating it hehe :)

My question now is for which user are we designing it? The orgs we've been talking to? Bitmask's? Those are completely different mental models and behaviours. What could work perfectly for one can be a disaster for another

💔

[SweetVirginia]

From @olabini on July 12, 2016 15:37

The problem with the trusted contacts approach is that as it is right now, it doesn't have any security. (If Pixelated will send an email with a code to the trusted contacts WHEN an account needs to be recovered, that implies that the Pixelated server either has the codes stored, or can create them on demand - which means that the server has the capability of recovering the account without trusted contacts. That means there is no real security here).

The only approach I know of that would work with trusted contacts, is that you generate the codes when the account is signed up, and Pixelated mails those codes immediately, and then forgets them. Of course, that puts these codes in the inboxes of other people, and they have to manage those things....

[SweetVirginia]

From @bwagnerr on July 12, 2016 17:37

@olabini Hey Ola, that second case is exactly what we thought of, creating a code on sign up and sending it to a secondary email address, so the user could recover it's account using the other one if he lost access.

[SweetVirginia]

So I roughly prototyped 3 solutions to test:

1) Backup Codes: at sign up people get a few backup codes to download. In case they lose their password they can use it. The problem with this is if people lose their password, it does seems likely to lose the backup codes too. Furthermost, people tend to take pictures of the codes with their phones which can be a harmful workaround.

2) Trusted Contacts: at sign up people inputs 3 or 5 email accounts from people they trust. Codes are sent to those inboxes. In case of lost password, those codes will be used to recover account. In informal paper prototypes and conversations with people, I observed that the first "trusted contact" people put was their own personal email (gmail/yahoo etc.). So it is a workaround that takes people to the normal paradigm: backup accounts.

3) Sysadmin as a Trusted Contact: at sign up people input a backup email account of their preference and use their sysadmin email as a trusted contact. In case of lost password, they'll use the code sent to their inbox and a code (sent at signup) provided by the sysadmin. The problem with that approach is in case the sysadmin is not so available, people may feel locked out from their accounts.

Some rough prototypes to be tested, you can comment there if you want: https://invis.io/7P8AJ3YRK

One of the possibilities is to, in the future, have those different options of account recovery available at installation and the sysadmin may choose accordingly to organisations's threat model. :)

[SweetVirginia]

I just realised InVision opens the mockup not in the way I intended. Once you click on the here there's this:

click on the"grid" button to see mockups for each solution :)

[deniscostadsc]

First of all, congrats for all people involved in this issue. Beautiful job!

I have a few questions:

• Did we already discarded recovery based on trusty users? As Ola pointed it seems not a secure method.
• Why we didn't drew something based on a secondary account of the same user? Google uses that as one the the method to recover the user account.
• How are we going to validate these hypothesis?

[SweetVirginia]

Did we already discarded recovery based on trusty users? As Ola pointed it seems not a secure method.

Depends on the implementation. That's why we didn't discard yet.

Why we didn't drew something based on a secondary account of the same user? Google uses that as one the the method to recover the user account.

If I understood right we did, "Sysadmin as a Trusted Contact" is that approach, their personal account with an "extra layer", which is the sysadmin. If is not that, please clarify because I'm not so sure I understood 😮

How are we going to validate these hypothesis?

Qualitative research with our users, random strangers and some remote testing. I'm planning those tests and I would like some one pairing with me to make those mockups real ❤️

[olabini]

Hi,

As V mentions - trusted users is not out of the question as a solution. It can be secure enough as long as the codes are sent out when the account is set up (or when editing trusted contacts). What is NOT secure is to have Pixelated send out the codes when a user has lost their account.

The approach V has drawn up is a bit more secure when it comes to the secondary account. The proposal does NOT allow a user to just use their google account to recover the Pixelated account - that would reduce the security to the security of the google account. Instead, by requiring a sysadmin AND the secondary account, we get better security, with decent usability. Hopefully. =)

[cz8s]

There really is no difference beteen scenario 2(trusted contacts) and 3 (trusted admin as contact). except that more people are involved. right? I thought the admin didn't receive a code but could just enable or disable password resets for accounts. In this scenario, a user would have a password reset code stored in ther hotmail email but this code could only be used if the admin enabled password reset for that account. Depending on the org, it might not take much social engineering to get admins enabling password resets for any account. no? What is the upside ov virginias approach sending the code to the admin email instead of just offering a checkbox in the webapp?

[varac]

I'm still a fan of the backup code. Yes, ppl are sloppy and some might print it out and put it under their keyboard, but hej, then they probably will do the same with their password anyway.

Doing it right this is the best combination of a) simple to implement and b) secure enough. We should take much care on implementing this good from an UX perspective, i.e. giving advices how to best store the code (and how you shouldn't). Making it resonable long but hopefully just so long that users that cannot print it can easily write it down etc.

The problem with the trusted contacts is that i see many case where contacts can access their code because their are away/travalling, forget their password, abandon their account, etc.... It's harder to implement, some codes will be send out unencrypted (or prone to tls downgrade attacks). I thought about doing the same for a distributed recovery key for my personal backup, using shamir's secret sharing. But i decided against it so far because I fear that in the hour of most despair, one or more of those conditions will happen.

I'm sceptical about the Sysadmin as a Trusted Contact approach because first one part of the backup key will get send probably unencrypted over the wire (same reasons as above) to an untrusted provider, and then it's just a social engineering hack away from convincing the admin to reset your account, if this code gets in the wrong hands. Maybe I have not thought it through entirely, correct me if i'm wrong.

Both methods that require sending codes out to other accounts should take into account:

• How do we validate that the email recieved the contact/inbox ?
• What to do in the case of those inboxes get compromised ? So both these approaches seem to be more complicated and don't offer much improvements over the backup code approach, imho.

I think it would be good to also discuss this topic on the leap discuss mailinglist, to see if we find common ground together with LEAP devs and external contributors. @SweetVirginia What do you think ?

[varac]

oh btw, the leap-webapp already has an out-of-band email contact field in the account settings that can be used for the Sysadmin as a Trusted Contact approach:

Contact Email

You may specify an email address where we can contact you if there is a problem with your account. For privacy reasons, you might prefer to leave this empty. 

[..................]

[olabini]

Responding to cz8s comments: From a purely technical perspective, the difference between the sysadmin and regular trusted contact is nothing. They can both be implemented using the same code primarily - but you can do a bunch from a usability standpoint that for lots of people will make the sysadmin thing much easier to use while keeping the security OK.

Having the "reset account OK" flag for a sysadmin is LESS secure, since that means an attacker or the server only needs ONE code to be able to reset the password. By separating the capability of reset to the sysadmin, but not to the server, the system becomes potentially much stronger.

[olabini]

Varac: I'm not against backup codes at all. But @SweetVirginia has convinced me that from a usability perspective they are not necessarily the best solution for many of our users. You say that "some" users will treat the codes badly, while my feeling is that "most" users will treat the codes badly. Now, for some threat models that's OK - but for some it isn't. That's also where the idea of having different policies around account recovery makes sense. Different installations will have different needs.

[olabini]

Varac: I agree, that these things are potential problems. But that can also be tweaked by having different parameters for the secret splitting. Recovering an account should not be easy. It should be possible. All the reasons you propose as negatives are exactly the same for other recovery options.

[olabini]

Varac: finally, yes - the sysadmin solution is susceptible to social engineering attacks. So are any trusted contacts approaches. We are not saying that this solution is fool proof, but if your sysadmin can't be trusted to do his job in sensitive organizations, you have other problems anyway.

You can always guarantee that the sysadmin has encrypted email. And then it's just a matter of setting the parameters correctly. For almost everyone, the threat will not be someone that can break into gmail AND convince the sysadmin of a small pixelated instance to give up the recovery code. And for the places where this really is a realistic threat model, you can tweak it - require more trusted contacts from different providers, etc.

[varac]

@SweetVirginia: I'm usure how to review/QA this. Do we have a clear outcome of this discussion ?

[rdevries-thoughtworks]

A few question and remarks:

• When I enter my reset token on the website, will I be able to change my password immediately? Or will I get an email with a link to a reset page? And if so, will I have to enter the token there again?
• Will it be possible to reset my password directly, or will there be a 'cancellation period'? Pixelated could for example send an email/sms/... to notify the user of the reset attempt, and if it was actually a malicious attempt, the user could still cancel the reset in the coming hour/day/configurable timespan.
• As an alternative to the previous suggestion, the account could be unlocked for immediate use, but the past mails will only be encrypted after some period. I'm just brainstorming here, this is probably too complex to implement for now, but it might give you some inspiration ;-)
• Anything you don't do often (enough) you will forget, so if you ask people to store the email somewhere safe, they might not be able to find it back after a while (this would almost make you hope they forget their password regularly). In gmail, searching will probably make this easy, but what about other mail providers? Or do we just assume gmail? And should we put a specific string in the mail that's easily searchable? Note that testing this is very hard, because it's hard to simulate time gone by.
• Is it possible to reset the reset code?

[varac]

While talking yesterday we also thought of the situation of users that create an account now, before implementing this feature. Those users should be able to request the/a unblock code later (as users should be able to do if they loose access to their backup account or the mail with the reset code itself). So we need a 'request a new backup code' feature (not completely sure if this is possible from the current design).

[deniscostadsc]

As I said on our 1:1, to think on the UX of the reset code retrieval I recommend take a look on https://github.com/settings/tokens.

It is a completely different think, but Github does this in a smart way. User can just copy a specific code once. So the reset code are not exposed there forever. I think the sysadmin should have a similar interface.

[olabini]

Hey So - my perspective on these questions:

• having a reset token trigger a reset email doesn't make any sense to me - especially since there is nothing that reset email can contain that doesn't exist in the reset code. Remember, if the system HAS the capability to reset the account without the codes, then we have no real security.
• it might be a good idea to say you can only reset your account X amount of times per month or something. ideally this should be configurable by the sysadmin.
• don't see the benefit of waiting with unlocking encrypted email
• yes, finding the email is definitely a problem. we should make sure there's plenty of unique material in there for search, and we might even say something on the reset page "the email with the code was sent from pixelated-accounts@domain.com with the subject line "PIXELATED ACCOUNT RECOVERY CODE" etc.

When it comes to resetting things, I think of this stuff the exact same way as the more generic functionality of trusted contacts - and you would need to be able to edit those contacts etc. In the same way, resetting the reset codes and sending out new ones is part of that functionality.

[rdevries-thoughtworks]

having a reset token trigger a reset email doesn't make any sense to me

Good to hear; I had the same impression, but wanted to verify.

don't see the benefit of waiting with unlocking encrypted email

If your account is hacked, then this would give you some time to e.g. call the sysadmin to block your account, so your previously sent mails are not exposed to the attacker.

[olabini]

I'm not sure if that gives you more than a negligable security. And it requires a reliable way of telling the user their account has been reset - something we can't really do. That stuff works for large centralized providers, but not really for the Pixelated model

[SweetVirginia]

@re-nobre and @olabini and I drafted some flows about the Sysadmin as a Trusted Contact approach. I'll create a new issue with that outcome so we can have a more pragmatic discussion about the approach itself and start planning how to implement 😸

[elijh]

When I enter my reset token on the website, will I be able to change my password immediately? Or will I get an email with a link to a reset page? And if so, will I have to enter the token there again?

LEAP's plan is that you can reset the password immediately.

Is it possible to reset the reset code?

LEAP's plan is that you can obtain or generate a 'recovery code' any time you are authenticated.

[elijh]

It is important to distinguish between password reset, which is ultimately just a policy decision of the provider, and 'email archive recovery', which is a cryptographic matter.

Any provider admin can always just decide to change a user's password. There is nothing we can ever do to make this impossible, short of going to pure peer to peer.

In most cases, people would rather be able to use their account again and lose all their email archive over losing both the archive and the ability to login.

So, I suspect, some providers will want a normal password reset capability that works exactly like any other: you enter a secondary email or a secondary phone number and you can have a reset code sent to these addresses. And you lose access to your archive.

A "recovery code", as we call it, is only needed if you want to be able to reset the password and keep access to your mail/contacts archive.

The threat models are a bit different.

1. people for whom easy resetting is OK
   Almost everyone has done or said something in their email archive that they want to eventually keep private (even if they don't know it now). The vast majority of state overreach in applying pressure to service providers comes in the form of requests for historical data.
   Most people are probably happy with a system where password resets are easy, at the cost of losing their archive. These people are protected from law enforcement subpoena's of their email content, but they can otherwise use the email as they expect.
2. people for whom easy resetting is BAD
   On the other hand, everyone is a target to have their email account credentials stolen, if for no other reason than an email account has value to spammers. As we have seen, easy password reset mechanisms are a blight on the internet.
   But the larger issue is that there is a separate threat model for people who might be the subject of ongoing targeted surveillance or impersonation. For these people, it is actually really really important that the password is difficult to reset. Also, it is very likely that the people who fall in this category have no idea that they do.

The difficult is that there is no "one size fits all" approach for every user, and it is difficult to try to communicate the trade-offs to users. Every time we add another "option" where a user needs to make a choice that has security implications, we are opening a door that many people will mistakenly walk through.

Having said all that... I think I am in favor of an alternate email field that allows you to reset your password just like a normal email account, despite all the problems with giving users a rope to hang themselves with. We could add a warning message that (a) this makes it a lot easier to compromise your account (b) in order to recover your mail archive, you will need a recovery code not an email. I am torn, because you have already failed if you are relying on warning messages.