A bad experience with 2FA recovery codes

[jaraco]

I've been getting nagging emails and banners about setting up recovery codes. I had no interest in setting up recovery codes because I have my 2FA configured with redundancy, but rather than complain about it, I decided simply to generate the recovery codes to suppress the messaging.

When I did, I ran into additional issues. I generated the recovery codes and like a responsible person, I stored the codes in my password manager, a secure place I'd likely think to search if I needed them. I then closed my password manager and hit continue, only to find that I needed to burn one of the recovery codes to verify that I'd stored them safely.

So I unlocked my password manager again and cut out the last recovery code. Since it won't be usable again, I didn't want to leave it in the list of codes. I then closed my password manager, not realizing that it would clear the clipboard on close, so by the time I got back to my browser, the code was gone and was now irretrievable.

Thankfully, the workflow allowed me to regenerate the codes, so I went through the process again, this time being careful to paste the recovery code into the form before closing my password manager.

I've generated recovery codes for other services in the past, but I've never encountered this kind of experience. I've never had to use a recovery code to prove I knew how to save recovery codes. It feels a little heavy handed.

In any case, I'm all set up with recovery codes. I'm only posting this to capture a less than pleasant experience.

[di]

Thanks for the 'friction log' @jaraco -- I'm curious if you have any suggestions as to what would make this better besides removing the requirement to 'burn' a code.

[woodruffw]

Just chiming in: I've used services that require a user to "burn" a code to prove that they saved them correctly.

I agree that the current UX is tedious, though. A possible improvement: we could make the "burn" more upfront -- instead of being a separate view that we render after generating the codes, it should be part of a validation we perform when the user hits "Continue."

[jaraco]

What about adding an ability to opt out of the recovery codes, with an acknowledgment of the consequences?

I did notice there's at least one workflow dependent on having requested recovery codes - the ability to enroll with a security device, so that requirement would need to be severed (or dependent on the opt out). I don't understand what the relationship is between having recovery codes on one auth method and enrolling with another auth method.

[dstufft]

I think the problem with "acknowledgement of the consequences", is that I don't think you really can do that?

At the end of the day, the consequences are that you're more likely to require admin intervention to recover your account, unless we take a hard-line stance against helping to recover accounts from people who opted not to generate recovery codes. However, I have a hard time imagining us being willing to say that hey "Jason lost his codes, so now some number of widely used projects are just SOL and he needs to register a new user and possibly make whole new names for that project".

IOW, I think the consequences affect more people than just the user in question.

[jaraco]

It's not been my experience that loss of 2FA means the backing resources are lost forever. My expectation (acknowledging that PyPI could have a different policy) would be that if someone lost their 2FA and recovery codes, they would lose any automated access to recover the account and they would need to escalate to manual intervention, which may take days or weeks and require any level of manual re-authentication, revocation of keys or access, payment of fees, etc.

[dstufft]

Right, that's what I mean. If a user on PyPI loses their account, it requires the PyPI admins to take extra effort, that's the "manual intervention" part, so the consequences of a user not having recovery codes are not borne entirely by that user, but also by the PyPI admins themselves.