How to send a password securely

Send it as a one-time link from a dedicated tool, not as text in an email or chat. The link self-destructs on first view, so no lasting copy exists for anyone to find later.

That's the short version. The rest of this page is why the obvious approaches don't work, what the realistic options are, and how to pick between them — including the cases where you don't need to pay anyone.

Why the obvious approaches fail

Email. A password in an email exists in at least four places the moment you press send: your sent items, their inbox, both mail providers' storage, and any backup either organisation runs. It's searchable for years. If either mailbox is later compromised — or simply left signed in on a laptop in a coffee shop — the credential goes with it. Email was never designed to forget things, and that is exactly what you need here.

Slack, Teams and chat. Better in transit, no better at rest. Chat history is searchable by design, often retained indefinitely on a paid plan, and visible to anyone added to the channel afterwards — including people who join the company next year. Editing or deleting the message doesn't reliably remove it from exports or from the notification someone already received on their phone.

A shared document. The worst option that feels organised. A credentials tab in a shared sheet turns one password into a standing list of them, usually with link sharing switched on so nobody has to ask for access. It persists long after the project ends and nobody is quite sure who can still open it.

Splitting across two channels. Username by email, password by SMS. It genuinely raises the bar for an attacker who only has one channel — but both halves still persist indefinitely, and it takes twice as long, so in practice people do it for the first two handovers and then stop.

Password-manager sharing. A real answer, with a real limitation — see below.

The realistic options

A free one-time secret tool

Onetimesecret and similar free services do the core job well: paste a secret, get a link, the link works once. Several encrypt in the browser so the key never reaches their server.

Choose this if you send a password now and then, it doesn't matter that the page carries someone else's brand, and nobody will ever ask you to prove the handover happened. For a lot of people this is genuinely the right answer and we'd rather say so than pretend otherwise.

A self-hosted tool

PrivateBin is open source, runs on your own server, and encrypts in the browser — the server never sees the key or the content.

Choose this if browser-side encryption with no server-held key is a hard requirement, or your security policy says the data can't touch a third party. The cost is that you now run and patch a service.

Your password manager's sharing feature

1Password, Bitwarden Send and similar let you share an item or generate an expiring link.

Choose this if you already pay for one — the sharing is included, and for internal handovers between colleagues who both use it, it's the path of least resistance. It gets awkward when the recipient is a client who doesn't use the same tool, or any tool.

A dedicated secret-sharing service

Tools built for the handover rather than for storage — SecretWolf is one — add the things the options above structurally can't: your own branding and domain on the link, a way to request a credential inbound, verifying the recipient's email before anything reveals, and a record that the handover happened.

Choose this if handing credentials to clients is part of the job rather than an occasional errand.

Where SecretWolf fits — and where it doesn't

SecretWolf sends a credential as a one-time, AES-256-GCM encrypted link that is hard-deleted on first view or at expiry. You can put it on your own subdomain or custom domain, require the recipient to confirm a code emailed to them before the secret reveals, and keep a metadata-only audit trail — who received what and when, never the value itself. That last part is usually what turns a nice-to-have into a purchase: it's the evidence a client's security review asks for.

Where it doesn't fit. SecretWolf encrypts server-side and holds the encryption material while a secret is live. If your requirement is that no server ever holds the key, a browser-side tool like PrivateBin is the honest recommendation. It is also not a password manager — it handles the handover, not long-term storage, and sits alongside 1Password or Bitwarden rather than replacing them. And if you send one password a quarter, a free tool will do the job perfectly well.

More on the mechanics: how SecretWolf encrypts and deletes secrets. In context, it's the same handover whether you're an agency passing a client their CMS login or a service desk sending a reset.

Questions people ask