How to send a password securely
The risk is not interception. It is the copy that sits in a chat archive for three years.
Somebody needs a password from you — a colleague, a client, a contractor starting on Monday. The fast way is to type it into a chat window. This page explains why that keeps costing organisations money, and what to do instead when you have thirty seconds, not a rollout budget.
The problem is not interception. It is persistence.
Most advice about sending passwords worries about somebody reading the message in transit. That is largely solved: your email and your chat app almost certainly use TLS between you and the server. The real problem is what happens after the message arrives.
A password typed into a chat window is still there in six months. It is in the sender's history, the recipient's history, the workspace's search index, the compliance archive, the backup of the compliance archive, and on the phone of anyone who was later added to that channel. It is in the laptop backup of a person who has since left. Nobody decided to keep it. Nothing deleted it either.
That is what turns one shared credential into an incident two years later. Not a wiretap — a search box.
What to do instead
- Put the password in a note here. It is encrypted in your browser with AES-256-GCM before anything is transmitted. The 256-bit key is generated on your device and placed after the # in the link — the one part of a URL browsers never send to a server.
- Send the link through whatever channel you already use. Chat, email, a ticket, a text message. The channel no longer needs to be trustworthy for storage, because what sits in that history is a link that stops working after it is opened once.
- Tell the recipient it opens once. This is the only part people get wrong. Say it in the same message: "this link works one time, open it when you are ready to save the password."
Set the expiry short — ten minutes or an hour if they are at their desk. Set the view count to one unless you have a specific reason not to.
When the recipient opens the link, the note is deleted from the server as it is handed over. If they later find the link dead, that is information: either they already opened it, or somebody else did. A password-sharing method that tells you when it has been used is worth more than one that silently works forever.
Why the key in the link matters
Everything after the # in a URL is the fragment. Browsers use it locally — to jump to a heading, for instance — and by specification they do not include it in the HTTP request. So when your browser fetches the note, the server receives the note's identifier and nothing else.
The practical consequence is what makes this worth doing: we cannot read your password even if we want to, and neither can anyone who compels us. A demand for the contents of a note yields the ciphertext, which is unreadable without the key, and the key was never here. This is not a promise about our conduct. It is a statement about what exists on the disk.
The full technical account is on /security, and /verify lets your own browser check that the code we served you is the code we published.
Practical notes
Send the username separately, or not at all. If the password link is intercepted, a username in the same message hands over both halves. Usually the recipient already knows the username.
Do not paste the link into a group channel. Whoever reads it first consumes it, and the intended recipient gets a dead link with no way to tell who took it.
Expect it to be used immediately. If you send a one-time link at 11pm and they open it at 9am, that is nine hours in which anyone with access to that inbox can open it first. Shorter expiry is better than longer.
For a password the recipient will need repeatedly, this is the wrong tool. Use a shared password manager vault. This is for handing something over once, not for storing it.
Rotate anything that has been in a chat log. If you are switching to this method because a password has been sitting in Slack since 2024, change the password too. Moving to a better channel does not un-share what was already shared.
What this costs
Nothing, and there is nothing to sign up for. No account, no email address, no cookies. That is not a pricing decision so much as a design one: an account would mean a record linking a person to the secrets they sent, and the point of the exercise is that no such record exists.
Do it now
Write the note on the home page. If you need to send a file rather than a password, /files works the same way — the contents, the filename and the file type are all encrypted in your browser. If you need a short back-and-forth instead of a one-way handover, /chat opens a room that erases itself minutes after everyone leaves.
Related: sharing an API key or access token, how a one-time secret link works, and the questions people actually ask.