The short answer: which method for which situation
Most password-sharing advice argues about tools. The useful question is simpler: how long does this credential need to live, and who needs it? Answer that and the method picks itself.
| Situation | Use | Why |
|---|---|---|
| A credential the whole team uses for months (shared SaaS login, service account) | Shared vault in a password manager | It has to stay current, be rotated in one place, and be removed from people who leave. |
| A one-off hand-off (new hire's first login, client's admin password, a contractor's database string) | One-time secret link | The value is read once, then destroyed. Nothing stays in anyone's inbox or chat history. |
| A password for someone outside your vault (client, vendor, freelancer) | One-time secret link, passphrase sent separately | You cannot invite outsiders into a company vault; a link plus an out-of-band passphrase needs no account on their side. |
| A single Wi-Fi key or door code, in person | Say it out loud | No copy is created. It does not scale and typos happen, but for one value it is fine. |
| Anything, ever | Not email, Slack, Teams or SMS | All four keep a searchable copy you do not control. See why they are the worst channels. |
The 5 ways teams share passwords, compared
Every method below is in daily use somewhere. The table compares them on the properties that matter after the password has been sent — because that is when things go wrong.
| Method | Who can read it later | How long it persists | Revocable | Audit trail | Recipient friction | Best for |
|---|---|---|---|---|---|---|
| Password manager vault | Vault members with access | Until you rotate or remove it | Yes (remove access) | Yes (event log on team plans) | Needs an account and an invite | Long-lived team credentials |
| One-time secret link | Only the first person to open it | Until first view or expiry (LinkPilot: 1 hour, 24 hours or 7 days on every signed-in plan, a custom date and time on Pro; the no-account tool defaults to 7 days) | Yes, until it is viewed | Yes (created / viewed / burned / revoked) | None — a link and, on Pro, a passphrase | Hand-offs, onboarding, outsiders |
| Chat (Slack, Teams, Signal) | Channel members, admins, future joiners, exports | Workspace lifetime by default on paid Slack plans | Delete removes one copy; exports and screenshots remain | Partial (admin audit, not per-secret) | None | Nothing sensitive — send the link, never the value |
| Both mailboxes, both providers, backups, every synced device | Indefinitely | No | No | None | Carrying a link to a secret, never the secret | |
| Verbal, phone or SMS | Verbal: nobody. SMS: both handsets and the carrier | Verbal: not at all. SMS: indefinitely | No | No | Low, but typo-prone | A single value, in person |
Checked 2026-10-02. The Slack retention default and the SIM-swap figures are cited in the sources at the end of this guide; LinkPilot behaviour matches the security architecture page.
Shared vaults in a password manager
For credentials that live for months, a shared vault in a password manager — 1Password, Bitwarden, Keeper, Psono and others — is the correct default. The password sits in one place, rotation updates it for everyone, access is granted per collection, offboarding is a matter of removing a seat, and team plans add event logs. The trade-off: everyone who needs the password must be inside the vault, so a client, a freelancer or an unprovisioned new hire cannot be handed a vault item.
A one-time encrypted link
For the hand-off moment, a one-time secret link is the right tool. You paste the password, get a URL, and send it through whatever channel you already use. The recipient opens it once; the payload is revealed and then destroyed, and the URL left behind in the thread points at nothing. Add a short expiry so an unopened link dies on its own, and a passphrase delivered through a second channel so an intercepted link alone is useless. You can create one now without an account; LinkPilot vs Password Pusher and how to share API keys securely cover the same mechanics for tokens.
Chat (Slack, Teams, Signal)
Chat feels ephemeral and is the opposite. Slack's own documentation states that on paid plans "data is kept for the lifetime of your workspace by default", and workspace owners can export it. Teams and Google Chat sit under retention and eDiscovery policies built so messages cannot be made to disappear. Signal is better — disappearing messages, no server-side history — but it is still a copy on two phones with screenshots and backups you do not control. And every chat client unfurls links the moment they are posted, which is why a one-time link must be designed so a preview cannot burn it.
An emailed password sits in plaintext on the sender's mail server, the recipient's, the backups of both, and every device that synced the mailbox. It survives forwarding, archiving and account compromise, and a mailbox breach years later surfaces every credential ever sent through it. Email is a fine way to carry a link to a secret; it is never a fine place to put the secret.
Verbal, phone and SMS
Reading a password aloud in the same room creates no copy at all — the only zero-residue method on this page, and the only one that does not scale. SMS is the dangerous cousin: the message persists on both handsets and in carrier records, and phone numbers get stolen. The FBI's Internet Crime Complaint Center logged 1,611 SIM-swapping complaints with more than $68 million in losses in 2021 alone, up from 320 complaints across all of 2018–2020. SMS is acceptable for a short passphrase that is useless without the separately delivered link; it is not acceptable for the password itself.
Why email, Slack and SMS are the worst channels
Email, chat and SMS share one property that disqualifies them: they are retention systems. Each is built to keep a faithful copy of every message, forever, in places you cannot see. A password pasted into any of them is effectively published to your future attacker. Specifically:
- Indefinite retention. Slack keeps paid-workspace data for the workspace's lifetime by default; mail servers keep mail until someone deletes it, and backups keep it longer.
- Admin and export access. Workspace owners can export chat history and mail administrators can open any mailbox, without the sender's permission.
- eDiscovery and legal holds. Holds exist to stop messages being deleted. A password caught in one cannot be scrubbed.
- Forwarding and screenshots. Every copy can be copied again; the number of places a plaintext password lives only goes up.
- Link unfurlers and security scanners. Chat clients and email gateways fetch every URL as soon as it is posted. A naïve secret link is burned by the preview bot before the human opens it — see how LinkPilot prevents that.
- SIM swap and shoulder surfing on SMS, with the carrier holding a copy too.
The fix is not a better chat tool; it is to change what travels through the channel — a pointer that dies, not the value. More in why URLs leak sensitive information.
Password manager or one-time link? When to use which
They are complements, not competitors. A vault is storage; a one-time link is delivery. The vault holds the credential for as long as the team needs it; the link moves it to someone, once, and leaves nothing behind.
If a credential will be used repeatedly inside your organisation, share the vault item. If it has to reach one person once — especially someone outside your vault — send a one-time link. The anti-pattern is email or chat for either job. More in secret links vs password managers.
How a one-time secret link actually works
No "military-grade encryption" claims here. This is the real model, and it matches our security architecture page line for line — if the two ever disagree, that page wins.
Encryption happens in your browser
Since 29 September 2026, the payload is encrypted client-side with AES-GCM-256 using a 256-bit key generated in your browser, before anything is sent. What reaches us is ciphertext, in a secret_links table isolated from the click-analytics tables. Attached files are encrypted the same way with a key derived from the secret's own key, so one link opens both. Engineering detail: client-side encryption for secret sharing.
The key lives in the URL fragment
The share link looks like shrd.link/s/<slug>#k=<key>. Everything after the # is the decryption key, and browsers never send the fragment to any server — not to us, not to the CDN serving the reveal page. We never receive the key, so we cannot read the secret, recover it if the link is lost, or reproduce the URL later. Stated plainly: anyone holding the full link holds the key.
Passphrases add a second factor
On Pro, a passphrase is stretched with PBKDF2-SHA256 (210,000 iterations) and combined with the link key through HKDF-SHA256, so neither the link alone nor the passphrase alone decrypts the secret. Separately, a SHA-256 hash of the passphrase is sent so the server can refuse to return the ciphertext to a caller who does not know it; the raw passphrase is never written to our database or logs. Attempts are rate-limited to 5 per IP per minute per secret, and every failure lands in the audit log. For context, NIST SP 800-63B requires stored memorized secrets to be salted and hashed with a key derivation function such as PBKDF2 at a minimum of 10,000 iterations.
Burn-after-read is atomic
A burn-after-reading link gives the recipient one chance to see the contents. The view is recorded through a single database function with row-level locking, so two people opening the link in the same instant cannot both read it. At the view limit the status flips to burned and the stored payload is overwritten with [REDACTED]; later visits get HTTP 410 and a clear "already viewed" page. Expired and revoked secrets are redacted the same way, and there is deliberately no restore.
Link previews cannot burn it
A GET on the reveal endpoint returns metadata only — status and whether a passphrase is required. A view is recorded solely on the explicit POST a human triggers by clicking reveal, and every reveal response carries Cache-Control: no-store. Chat clients and email security gateways fetch links as plain GETs, so their previews see nothing and burn nothing. A test you can run: link scanners and one-time secrets.
What we can still see — three honest limits
- Secrets created before 29 September 2026 were stored as plaintext until they expired. They were never silently rewritten; they kept working as before and aged out on expiry. An operator could have read one while it was active. Attachments uploaded before that date remained stored as plain files.
- Anyone holding the full link holds the key. Client-side encryption removes us, our database and our edge from the trust boundary. It does not protect a link that has been forwarded, screenshotted or logged on the recipient's side.
- A file's name, size and type stay visible to us. Those are metadata columns; the contents are not. Per reveal attempt we also keep a timestamp, a hashed IP (SHA-256 with a daily-rotating salt, truncated), coarse geolocation and the user-agent — never the secret, the raw passphrase or the raw IP, and no cookies on the recipient.
Audit trails and compliance: what an auditor asks for
When credentials change hands, an auditor asks three things: who sent what to whom, was it opened, and can you prove it is gone. A vault answers the first for insiders; a one-time link with an audit timeline answers all three for the hand-off.
- Per-secret events. Every secret carries its own timeline — created, viewed, failed_passphrase, burned, expired, revoked — each with a timestamp and a hashed IP. A view you did not expect is an interception you would otherwise never know about; rotate the credential.
- Evidence of non-retention. Burned, expired and revoked payloads are overwritten in the database, not merely flagged. "The password is no longer anywhere" is backed by the redaction behaviour, not a promise.
- Data minimisation. No raw IPs, no cookies on the recipient, no secret contents in analytics or AI features; the pipelines are separated at the data and code level. Our GDPR page documents the posture and the transparency page covers requests we receive.
- Honest scoping. LinkPilot does not advertise SOC 2, HIPAA or PCI DSS attestations for Secret Links. Treat it as a controlled hand-off channel inside your own compliance programme — the thing that replaces email and chat — not as a certified system of record.
Plan facts, so nobody discovers a cap after clicking: Free includes 5 active secret links with burn-after-read and the default expiry; passphrases, custom expiry and the full audit timeline are on Pro at $29/month; revoking needs an account, because the anonymous tool has no dashboard. Details on pricing.
If you run an MSP: onboarding, hand-offs and offboarding
A managed service provider shares credentials in three recurring situations, and each one has a different shape. The table says which method fits, using the same reasoning as the rest of this guide: how long the credential lives and who needs it.
| Situation | What to use | Why |
|---|---|---|
| Client onboarding: the first admin password, a router login, an M365 global admin account | One-time secret link, passphrase sent by phone or SMS | The client has no seat in your vault. A link that burns on first read leaves nothing in their inbox, and the passphrase on a second channel means an intercepted email alone is useless. |
| Credential hand-off between your own technicians (a ticket changes hands, an on-call rotation) | Shared vault for the standing credential; a one-time link for the rotated value | The vault keeps the current value in one place. When you rotate it, the new value travels once and is destroyed. |
| Offboarding a client or a technician | Rotate in the vault, then remove access; revoke any unread links from the dashboard | A link that was never opened is a credential still in flight. Revoking it is faster than guessing whether it was read. |
| Proof for an audit or a client security questionnaire | The per-secret timeline (Pro) | Created, viewed, burned, expired and revoked, each with a timestamp, answers "who had access and when" without a chat search. |
Two practical notes. First, the LinkPilot for Slack app creates one-time secrets from the channel your technicians already work in, so the link habit does not depend on remembering a website. Second, the free one-time secret link generator needs no account, which is useful when a client's own staff must send you a password: send them the link to the tool, not a request to paste it in chat.
A password-sharing policy you can copy
Most credential leaks in small teams come from habit, not attackers. Six rules remove the habit; copy them into your handbook as is.
Credential sharing policy
- Passwords, API keys, tokens and connection strings are never written into email, chat or SMS. Not once, not "just this time".
- Long-lived shared credentials live in the team vault. Share the vault item, not the value.
- One-off hand-offs use a one-time secret link with the shortest workable expiry and burn-after-read on.
- The link and the passphrase travel on different channels — link by email, passphrase by phone or a chat DM — and the passphrase is never reused.
- On onboarding, a new hire's starter credentials arrive as one-time links and are rotated at first login. On role change or offboarding, vault access is adjusted the same day and any credential the person held outside the vault is rotated.
- Anything that was ever pasted into chat or email is rotated the next time it is touched, and the chat message is deleted. Any unexpected view in a secret's timeline triggers an immediate rotation.
Vendors and contractors get the same treatment with one addition: their credentials get an expiry date in the vault equal to the contract end, and are rotated when it passes.
Create a one-time password link now
Paste the password, set an expiry, send the link. No account is needed for a basic secret; an account adds revocation and the timeline, Pro adds passphrases and custom expiry.
Sources
- Slack — Customize message and file retention policies ("data is kept for the lifetime of your workspace by default")
- FBI IC3 — Criminals Increasing SIM Swap Schemes to Steal Millions of Dollars from US Public (PSA, 8 Feb 2022)
- NIST SP 800-63B — Digital Identity Guidelines: Authentication and Lifecycle Management, §5.1.1.2 Memorized Secret Verifiers
- Bitwarden — About Send (text and file Sends, expiry, access counts)
- LinkPilot — Security architecture (the authoritative description of the model above)