The basic model, and where it quietly breaks
A self-destructing, encrypted note already does a lot: the key never touches the server, the note evaporates after one read, and there's no account tying it back to anyone. So why would you add a passcode on top of that?
The honest answer is that a passcode is useful in a narrow set of situations — and actively misleading in others. Understanding which situation you're in is the whole point.
What a passcode actually protects against
When you create a passcode-protected note, the note won't open until the reader enters the correct phrase. That sounds simple, but think about what threat it addresses: someone who intercepts the link but doesn't have the passcode.
That's a real scenario. Links travel through channels with varying levels of exposure. Slack DMs are logged. Email is indexed. A link sent to a shared inbox might be read by two people when you intended one. A passcode means that even if the link leaks — forwarded, screenshotted, scraped from a log — it's inert without the second factor.
This is most valuable when:
- You're sending the note to a shared or monitored channel where link visibility isn't fully under your control.
- You have reason to believe the link might be forwarded before the intended recipient opens it.
- The recipient is behind a corporate proxy that logs URLs (including fragments — more on that in a moment).
- You're sharing something with a high-value target: an executive, a client, a source.
The corporate proxy problem worth knowing about
Most developers know that URL fragments — the part after the # — aren't sent to the server. That's the foundation of how SecureNotes keeps the decryption key out of server logs. But fragments can be captured by certain browser extensions, endpoint monitoring tools, or corporate proxies that inspect TLS traffic after decryption.
In a tightly monitored enterprise environment, treating the fragment as invisible is optimistic. A passcode adds a layer that survives even if the full URL is captured, because the key alone isn't enough to open the note — you still need out-of-band knowledge.
If you're sharing recovery codes or MFA backup codes in contexts like these, the threat model for sharing recovery codes is worth reading before you settle on a workflow.
The mistake that makes passcodes pointless
Here it is, plainly: sending the passcode in the same message as the link defeats the purpose entirely.
If an attacker, a nosy colleague, or an overly broad compliance tool can read your Slack message, they'll see both. A passcode sent in the same channel as the link isn't a second factor — it's decoration.
The passcode has to travel through a different channel. That's the only rule that matters, and it's non-negotiable.
Choosing the right out-of-band channel
"Different channel" is vague. Here's how to think about it concretely.
The goal is that an attacker who compromises channel A cannot also read channel B without a separate, additional effort. Common pairings that work in practice:
- Link via email ? passcode via SMS or a phone call. Weak against someone with access to both your email and your phone, but fine against most passive threats like log scraping or inbox snoopers.
- Link via Slack ? passcode via a separate Signal message or a quick phone call. Better, because Slack and Signal have different access controls and are unlikely to be compromised simultaneously.
- Link via email ? passcode delivered verbally in a video call. This is actually quite strong, because the passcode is ephemeral and never written down.
- Link via a ticketing system ? passcode via the recipient's personal phone number on file. Useful for IT helpdesk workflows, where the ticket might be visible to multiple admins but the passcode is delivered privately.
For contractor onboarding scenarios — where you might be handing over API keys, admin credentials, or SSH keys — this pattern slots neatly into a broader workflow. See the post on sharing API keys with a contractor without leaking them into shared docs for how to structure that handoff end to end.
When a passcode is overkill
If you control the channel completely — say, you're sending a note directly to a colleague's personal Signal account, and you're confident they're the only one with access to it — a passcode probably adds friction without adding meaningful security. The self-destructing, encrypted link is already doing the heavy lifting.
Passcodes make most sense when channel hygiene is imperfect. And channel hygiene is almost always imperfect.
Choosing a good passcode
If you're going to bother, make it count. A passcode like welcome1 or the recipient's name is guessable. A passcode like crane-fossil-39-lamp is not. Use a short passphrase — three or four random words — that's easy to read aloud over the phone but not easy to guess. Avoid anything tied to the content of the note (don't use githubprod as the passcode for a note containing a GitHub production key).
And don't reuse passcodes across notes. If you have a standing passcode you use with a particular colleague, it's no longer really out-of-band — it's just a shared secret that grows more exposed over time.
A quick workflow you can actually use
- Compose the note and set a passcode — a short, random passphrase you haven't used before.
- Send the link via your primary channel (email, Slack, a ticket).
- Send or say the passcode via a different channel — ideally one that doesn't produce a searchable log.
- Confirm the recipient opened the note successfully. Once it self-destructs, the link is dead.
This is the same general discipline as two-factor authentication: the value comes from separation, not from the strength of either factor alone. If you're building this into a repeatable offboarding process, the credential rotation checklist covers how to handle the cleanup side once the handoff is done.
Share one secret, then forget it ever existed
A passcode-protected note, sent with the passcode through a separate channel, is about as clean a handoff as you can manage without specialized infrastructure. The note opens once, the passcode becomes useless, and there's nothing left in either channel that's worth stealing. Compose a passcode-protected note on SecureNotes and see how little friction it takes to do this right.
