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

Hey @PeterG_1P !

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? 😉

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

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.