🤐 Send and request passwords securely

But Why?

Because passwords and API keys should not live forever in Slack DMs, email threads, or iMessage histories. 🔑 clientkeys encrypts your secret in your browser and gives you a link that works once, then disappears — so nothing lingers where it should not.

Who is this for?

  • Freelancers sharing credentials with clients
  • Developers sending API keys to teammates
  • Individuals who want a one-time link instead of a permanent chat log

Why email and chat are dangerous for sharing passwords

  • They live forever. Chat histories are backed up and synced across devices, retained by employers for compliance, and stored in the cloud by providers you do not control, which means the password you sent last year is still sitting in a chat log on someone's laptop, their phone, and the provider's servers.
  • They leak through search. Slack and Teams are designed for discoverability — a coworker searching for a project name can stumble on an API key you shared six months ago — and link-preview crawlers from Slack, iMessage, and social media will eagerly fetch any URL you paste, including one-time secret links, before a human ever sees them.
  • They spread through incidents. When a device is lost, an account is compromised, or a company is breached, the attacker gains access not just to email and chat but to every credential ever shared in those channels, multiplying what started as a single point of failure.
  • They are not access-controlled. Anyone who joins the channel, searches the transcript, or has admin access to the chat platform can see everything ever pasted there, and when someone leaves the company their device backups may still contain your secrets long after their access was revoked.
  • They are visible to providers. Slack, Microsoft, Apple, Google, and Meta can all technically access messages stored on their servers — most do not scan them actively, but they can be compelled by subpoena, and breaches at these providers have happened before and will happen again.

How to send a password securely — what 🔑 clientkeys does

  • Encrypted before sending. Your secret is encrypted in your browser with AES-256-GCM, and the encryption key is placed in the URL fragment (the part after #), which browsers never send to servers — so the server, and we the operators, cannot read your secret even if we wanted to.
  • Burns after one read. When the recipient opens the link, the ciphertext is atomically deleted from our database. There is no second view, no backup, and no retention — once it has been read, it is gone for good.
  • No account required. Receiving a secret requires nothing at all: no sign-up, no login, no email. Just the link and a browser.
  • You get a receipt. A separate receipt URL tells you when the secret was viewed, so you are not left wondering whether it arrived safely.

Request a secret — not just send one

Sometimes you need someone else to send you a password. Instead of waiting for them to paste it into Slack, create a request link. They paste the secret once, it is encrypted end-to-end, and only you can decrypt it. No other tool does this.

  • Ask a contractor for their API key
  • Request a database password from a teammate
  • Collect credentials during onboarding
  • Get a secret from a client without emailing passwords back and forth

What you can share with a one-time link

  • API keys and tokens
  • Database passwords
  • SSH private keys
  • .env files and environment variables
  • Wi-Fi passwords
  • Encryption keys and recovery codes
  • Anything you would hesitate to paste into a public channel