How do I share a secret or credential with someone safely without email or chat?

Email and chat are designed for conversation, not secret custody. They create searchable copies, notifications, backups, exports, screenshots, and forwarding paths. A password or API credential pasted into a chat may remain accessible after the task is finished, even if the message is deleted from the visible thread.

The safest answer for a production credential is usually a secret manager with individual identities, audit records, access policy, and automatic rotation. A temporary handoff is a different situation: a contractor needs a test value, a colleague needs a one-time configuration, or a script must receive a short-lived token. In those cases, reduce the lifetime, scope, audience, and number of copies.

Threat model first

Write down what the secret protects and who must use it. A development API token and a production database password do not deserve the same workflow. Ask whether the recipient needs read access only, whether the secret can be regenerated, whether a second person must approve it, and whether the service handling the handoff is allowed to see plaintext.

Why a link is not a security boundary

A URL is easy to copy, and a URL containing a secret is particularly easy to spread. OWASP advises against putting sensitive data in URLs. Browser history, server logs, analytics, referrer headers, screenshots, and support tickets can all record it. Use a stable object address without the capability, then place the capability in an Authorization header.

Do not confuse HTTPS with end-to-end confidentiality. HTTPS protects the connection between the client and the server. The server can still see plaintext if you upload plaintext. If that server must not see the secret, encrypt it before upload and make sure the decryption key travels through a separate trusted channel.

A temporary handoff with HTTP

For a small temporary object, the public svc.nz shape is straightforward. Put the secret bytes into a named box, then give the recipient a read capability through a protected channel. The examples show placeholders only.

curl -X PUT --data-binary @temporary-secret.txt \
  https://in.svc.nz/handoff/credential.txt \
  -H 'Authorization: Capability YOUR_WRITE_CAPABILITY' \
  -H 'Content-Type: text/plain'

curl --fail --output credential.txt \
  https://out.svc.nz/handoff/credential.txt/latest \
  -H 'Authorization: Capability YOUR_READ_CAPABILITY'

Keep the capability out of email and chat if those are the channels you are trying to improve. A recipient could receive the object address in one message and the capability in a password manager, phone call, or separate authenticated system. The separation is not perfect, but it reduces accidental exposure.

Client-side encryption for a stronger boundary

If the service operator should not read the secret, use an authenticated encryption design implemented by a maintained library or tool. Encrypt on the sender's machine, upload ciphertext, and decrypt only on the recipient's machine. The key must not be sent in the same ordinary request as the ciphertext. A key in a URL fragment can stay in the browser and not be sent in an HTTP request, but key management still depends on the client and the person sharing it.

Authenticated encryption protects integrity as well as confidentiality. It lets the recipient detect modification or a wrong key. It does not prove that the sender was trustworthy, that the recipient's machine is clean, or that plaintext was not copied after decryption.

Expiry, one-time use, and rotation

Expiry limits future use, but it does not erase a copy that was already downloaded. One-time retrieval can reduce repeat access where the system supports it, but it cannot prevent a recipient from saving the plaintext. For a credential, the decisive control is rotation. Create a new credential, update the dependent system, confirm the old one no longer works, and remove the temporary object when your retention policy permits.

Anonymous boxes in svc.nz expire, which suits casual handoffs. The hosted product is currently a private trial, and the policy centre explains important limits around availability and deletion. Do not use an expiring object as a substitute for a managed production secret store or as proof of permanent erasure.

Common mistakes

People often share a root cloud key when a scoped read token would do. They leave the temporary object in a public channel, forget that terminal history records commands, or assume deleting the visible message deletes copies from notifications and backups. Another mistake is failing to tell the recipient what format to expect, which encourages them to paste a secret into a new insecure channel when parsing fails.

Give the recipient a short procedure: retrieve the object, verify the expected name or digest, place the value in a protected secret store, and confirm receipt. Then close the access path and rotate the value if the privilege warrants it. Document who owns that final step.

FAQ

Sources

OWASP Secrets Management Cheat Sheet; OWASP Transport Layer Security Cheat Sheet; NIST SP 800-57, key management; RFC 6750, bearer tokens.