Feature Request: Simpler way to save 2FA/MFA backup codes

HI @Ryan_Parman, thanks for this suggestion!

I could generate a PDF then store it someplace safe, but that someplace safe is 1Password.

Yeah, that's a compelling argument. This fits well with what we're trying to do: provide one safe place where you have everything you need to log in. So I can see why storing recovery codes in 1Password makes sense.

I have submitted a feature request to our developers on your behalf (thank you for the suggestion!) and will keep an eye on that going forward. 😃

In the meantime, the easiest thing to do might be to create a Notes field to your existing item and copy / paste the codes to be saved there. I understand that you're suggesting a more evolved workflow as a feature of the app, but want to make sure that you have a solution that'll work for you now, too. 👍

Hey @1P_PeterG !

In the meantime, the easiest thing to do might be to create a Notes field to your existing item and copy / paste the codes to be saved there.
That's how I try to use this. But I'm using a different vault that only consists of notes with recovery codes. 👌

I have submitted a feature request to our developers on your behalf
As I remember, there should already are requests for such a feature. Maybe you can stick them together to one request? 😉

Hey @DenalB, thanks for this!

As I remember, there should already are requests for such a feature. Maybe you can stick them together to one request? 😉

That may be true. I didn't happen to see one when I looked into this during the time of my last post, but not to worry - we periodically link or merge any accidental duplicate requests that come up, so if there is a pre-existing issue, this will be tied to that with no time lost in the triage and development process, and no customer suggestions excluded from the process. 👍

Hello team!

1password 8 has provided a new feature with a "special" section for Security questions, this is a fantastic addition, and I would like to suggest continuing on that path with the introduction of another special section "Recovery codes".
Many websites that support 2FA also generate recovery codes in case there is a drift between the client and the server time (or in case the seed has been entirely lost).

Those recovery codes are work keeping around, unfortunately there isn't quite a clear way to manage recovery codes in 1password as of now.
I personally have been creating a section called "Recovery codes" in which I store each of the individual codes as different password fields.
Admittedly it's a bit cumbersome; there are many entries in there (some websites provide more than 10 recovery codes [nextdns.io provides 20!!]), entering them manually can be a bit of a chore and afterwards they tend to simply hang around there taking a lot of visual space in the item card.

Creating a new dedicated section for recovery codes might be able to address both those concerns.
The latter one simply by allowing the "Recovery codes" section to be folded by default (arguably all sections should also be foldable).
The former one by allowing to edit all recovery codes in the section as a single text field which can be parsed by 1password and split in individual fields behind the scenes.

For the edit it might be worth going a bit more in the details.

In read mode it's a section folded by default, the user can unfold the section.
Once unfolded, each code is available as a single field; the codes can be copied/revealed/shown in large type.

In edit mode the entire section can be modified as a whole (an edit button next to the - button for the section for example).
Editing the section shows a single blob of text (similar to the notes section/field) with one code per line, read from the existing individual fields of the section. When saved, the blob of text is parsed (each line is trimmed, leading dashes are removed) and divided in individual fields for each recovery code, replacing effectively all the fields in the section that were there previously.
Each field in the section can still be edited/removed/sorted manually. For all intents and purposes the "section edit" suggested earlier is just an easy way to bulk enter/edit the codes.
The only caveat is that the field names should not be editable (or maybe even visible, after all those are undifferentiated recovery codes).

As an example here is what my cumbersome recovery codes section looks like at the moment:

1Password Version: 8.6.0
Extension Version: Not Provided
OS Version: Not Provided

@lightwood3983 What would be the purpose/value of keeping these recovery codes right next to the TOTP secret? I would suggest that in order for them to serve their purpose you'd have to store them outside of 1Password, which may be inadvisable for other reasons. For what it's worth, I do not store these codes at all. Your use case and threat model may be different, though. 😃

Ben

Presently, I store them in a new "Section" and flag each entry as "password". That way, at least the data is organized and not-so freeform. But that's a bit of tedium I'd hope to avoid in the future.

Speaking of merging... 😃 I've done some here.

Ben

Hihi Ben,

With regards to "why keeping those at all", there would be multiple reasons:
- Clock drift from the server or client that would lead to the generation of misaligned tokens
- User erratic manipulation leading to the removal/corruption of the totp seed in 1password that is currently unrecoverable
- 1password bug leading to corrupted tokens being generated

With TOTP being a dynamic value rather than a static one, there are numerous things that could possibly go wrong.
Some providers rely on 2fa to absolutely identify a user and some even more restrictive (or poorly design depending on the point of view) do not have a recovery path beyond the recovery codes.

You are correct as well, recommending to print and store those recovery codes somewhere else is advisable (and for some of them I do myself do that), but for ease of access I also believe that being able to store them easily in 1password is a valid use case.

Wanted to second this.

As an AWS user since 2006, I've had my AWS 2FA tokens drift over time, and needed a static code to reset the 2FA secret.