Security guides
How to share a password safely without leaving it in chat or email
Email and chat keep copies. This guide shows a short, practical handoff with an expiry, a separate password and an optional browser-held key.
Updated · 3 min · Free, no account required
A password sent in a chat message is a password stored in a searchable history, a notification, a backup and possibly a screenshot. The goal is not perfect secrecy; it is to reduce the number of copies and the time they exist.
Time: 3 minutes · Cost: free · Account: not required
Step by step
-
1
Open the editor on a trusted device
Go to okay.ovh in a private window. Check that the address is correct and that the connection is HTTPS before you type anything.
-
2
Paste the credential with enough context
Include the service, the username and the password so the recipient does not need a second message. Keep unrelated secrets out of the same paste.
-
3
Choose the shortest workable expiry
Ten minutes if the recipient is ready, one hour if they are not. A shorter lifetime is the simplest security improvement available.
-
4
Add a paste password and send it separately
Use a different password from the one in the paste. Send the link through one channel and the paste password through another, for example chat and a phone call.
-
5
Encrypt in the browser for a zero-knowledge handoff
Enable browser encryption when the content is especially sensitive. The key stays after the # in the link and is never sent to the server.
-
6
Enable burn after reading when one read is enough
Burn after reading deletes the row on the first successful open. Use it when the recipient is waiting and does not need to revisit the text.
-
7
Send the link, keep the manage link, then delete
The manage link is shown once. Keep it in a password manager so you can replace or delete the paste if the message reaches the wrong person.
Why chat and email are the wrong container
Chat platforms are built to retain and index messages. Email is copied to a sent folder, an inbox and often a backup or security gateway. Deleting the visible message does not remove those copies.
A paste with an expiry is different: the content lives at one address, the address stops resolving, and the author can delete it early. The message can still say what the secret is for, but it no longer contains the secret.
What the recipient experiences
The recipient opens one link, enters the paste password if one was set, and reads or copies the text. If the paste was encrypted in the browser, the key is in the fragment of the link and the page decrypts locally.
If the paste was configured to burn after reading, the first successful open deletes it. A second attempt receives a not-found response rather than another copy.
If the link or password leaks
Open the manage link and delete the paste immediately. If the credential was already read, rotate it at the source. The expiry limits the window, but it does not undo a disclosure that already happened.
For future handoffs, shorten the expiry, use burn after reading and send the password through a different channel. Those three changes remove most of the practical risk.
Frequently asked questions
Is it safe to send a password in a chat?
It is convenient, not safe. Chat history is retained and searchable, and copies can exist in notifications, backups and screenshots. Use an expiring link and send the paste password separately.
Should the password be inside the paste or used to protect the paste?
If the paste contains a credential, protect the paste with a different password and send that password through another channel. Do not reuse the credential as the paste password.
Does browser encryption protect the paste from the server?
Yes. The browser generates the key and keeps it in the part of the URL after the #, which browsers do not send to servers. The stored blob is ciphertext.
What is the safest expiry for a password handoff?
The shortest window that still works for the recipient. Ten minutes is appropriate when they are ready; one hour is a practical maximum for a live handoff.
Related reading
Use burn after reading
How burn-after-reading links work, when a single read is the right model, and how to avoid locking out the person who needs the text.
Read moreShare logs without leaking secrets
A practical redaction and handoff checklist for logs, stack traces and configuration files that may contain credentials or personal data.
Read morePasteOkay vs Bitwarden Send
Bitwarden Send is an encrypted sharing feature inside a password manager. We compare its account requirement, text limits and workflow with PasteOkay.
Read morePut the guide into practice
Create a paste, choose a short expiry and add a password. No account, no public feed and no third party scripts.