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

Ryan Parman

One of the areas of tedium I often encounter is managing the backup codes that are generated when I setup 2FA/MFA on a new account. They always tell you to print, but c'mon — it's 2022. I haven't owned a printer in years. I could generate a PDF then store it someplace safe, but that someplace safe is 1Password.

Yes, I know that having the backup codes next to the (T)OTP itself is a little redundant, but I've experienced a case where my TOTP code fell out of sync with a vendor, and needed the backup codes to login and re-sync so, y'know, shit happens.

What I would love to see is the ability to select the codes on the webpage, copy them, switch to 1Password (in edit mode for the Login entry), and paste. 1Password would be smart enough to resolve the \t and \n or \r\n characters, and store them as hidden/password entries in a new Section of the Login entry. (Capitalized words are specific areas in the 1Password UI.)

---

1Password Version: 8.6.0
Extension Version: Safari, v2.2.3
OS Version: macOS 12.3β

PeterG_1P

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. 👍

DenalB

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

PeterG_1P

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. 👍

lightwood3983

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

Ben

@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

Ryan Parman

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.

Ben

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

Ben

lightwood3983

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.

Ryan Parman

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.