How to share 2FA recovery codes securely
These bypass your second factor entirely. Treat them like it.
What recovery codes actually are
When you set up two-factor authentication, most services give you a set of backup codes. Each code lets you log in once without the second factor. They exist for the scenario where you lose your phone or your authenticator app. They're a bypass. Anyone who has one of these codes can skip 2FA entirely.
That's what makes sharing them different from sharing a password. A password plus 2FA is two layers. A recovery code is the key that removes the second layer.
The problem
A team shares a service account. The person who set up 2FA has the recovery codes. They paste them into a Slack DM so others on the team have a backup. Now the recovery codes are in Slack's search index, in the workspace export, in the compliance archive. Anyone who can search the workspace can find them.
Or someone screenshots the codes and drops the image in a shared Google Drive. Or emails them to themselves as a backup. Every copy is a permanent bypass to that account's second factor.
How to share recovery codes with Secret.Broker
1 Go to the tool and paste the recovery codes. Your browser encrypts them before sending anything to the server.
2 Set the view limit to 1 and the expiry to something short. An hour if the recipient is online. Recovery codes are sensitive enough that you don't want a link sitting around for days.
3 Use paranoid mode. It splits the link and the decryption key into two separate pieces. Send the link over Slack and the key over Signal, or any other second channel. If someone intercepts only one channel, they get nothing usable.
4 The recipient opens the link, enters the decryption key, copies the recovery codes, and the encrypted data is hard-deleted from the server. One view, then gone. No copy persists in Slack, no copy persists on the server.
Why paranoid mode matters here
For a regular password, a standard one-time link is usually sufficient. The password is one factor, and the account still has 2FA protecting it.
Recovery codes are different. They bypass 2FA. If someone intercepts the link in transit, they have a way past both factors. Paranoid mode adds a second channel requirement: the link alone is useless without the decryption key, and the key alone is useless without the link. Both pieces need to be intercepted from two separate channels.
For shared service accounts
When a team shares a service account with 2FA enabled, someone has to hold the recovery codes. If that person leaves the company, the codes need to be transferred. Create a one-time link with paranoid mode, send it to the next person, and the handoff is clean. No codes sitting in a Slack channel between team members who've since moved on.
After the transfer, store the codes in a password manager or secrets vault for long-term access. This handles the handoff, not the storage.
What the encryption does
Your browser encrypts the recovery codes on your device before anything goes to the server. The server stores ciphertext it can't read. With paranoid mode, the decryption key is split from the link entirely, so even the URL fragment contains only half of what's needed. The protocol page covers the full details.