How to privately share logins over email
Short answer: don't paste the username and password into the message body. Send the username by email and the password as an encrypted one-time link that expires in minutes. The mailbox then never holds a complete credential, and the sensitive half disappears after it is read.
Why email is a bad place to keep credentials
A message is not something that gets delivered and vanishes: it is a file that gets copied. It lives in the sender's Sent folder, in the recipient's inbox, in both providers' backups, in every synced desktop and mobile client, and sometimes in a corporate archive that retains everything for years for compliance reasons.
The practical result: a password typed into an email three years ago still works if nobody rotated it, and anyone who gains access to either mailbox finds it by searching for "password" or "login". No encryption has to be broken.
What goes wrong with the usual shortcuts
| METHOD | PROBLEM |
|---|---|
| Password in the message body | Permanent copy on several servers and devices; fully searchable. |
| Password in the subject line | Same as above, plus it shows up in notifications and previews. |
| Screenshot attachment | Still readable text, and it also lands in the phone's photo library. |
| Group chat or team channel | Indefinite history, visible to anyone who joins the channel later. |
| Shared doc holding the password | Permissions nobody reviews and a link that spreads unchecked. |
| Password split across two emails | Both halves end up in the same mailbox; no real gain. |
The method, step by step
- 01Split the credential in two: the identifier (username, email, login URL) and the secret (password, token, PIN).
- 02Write the normal email with the identifier and the context, leaving the secret out.
- 03Generate an encrypted link for the secret, with self-destruct on open and the shortest expiry that still works for the other person.
- 04Paste the link into the email, or better, send it through another channel (text, call, chat) so the mailbox holds neither half.
- 05Tell them the link is one-time: if an automatic preview opens it, they will need a new one.
- 06Ask for confirmation that it worked, and for long-lived access, ask them to change the password on first sign-in.
Why an encrypted link is actually private
In SecureShare the secret is encrypted in your browser with AES-256-GCM before it leaves the device, and the decryption key travels after the # in the link, a part of the URL browsers never send to the server. The server stores ciphertext it cannot read, and deletes it after the first read or at expiry. How that works under the hood.
I already sent a password in the clear: now what
- Change the password now, not later: a sent email cannot be recalled.
- Review recent activity on the affected account for sign-ins you don't recognise.
- Turn on a second factor if the service supports it; it makes the leaked password insufficient.
- Delete the message from Sent and ask the recipient to delete their copy: fewer copies, though never zero.
- If that credential was reused elsewhere, rotate it there too.
Rule of thumb: if a credential has travelled through a channel that keeps history, treat it as compromised and rotate it.
