How to share passwords securely
When you email an encrypted file, the weak link is rarely the encryption: it is the password you send in the same message. This page explains how to share it without leaving permanent copies, and how SecureShare works under the hood.
The email problem
A message is replicated on the sending server, the receiving server, backups, and both parties' devices. A password typed into the body stays readable for months, and anyone with mailbox access finds it by searching for "password". Sending the encrypted file and its key through the same channel is like taping the key to the door.
Practical rules
- Use one channel for the file and a different one for the password.
- Share one-time links with a short expiry instead of plain text.
- Avoid screenshots, group chats, and shared docs as password storage.
- Generate long random passwords, and never reuse them between sends.
- Confirm receipt, and treat the secret as burned after the first read.
Zero-knowledge architecture
SecureShare encrypts in your browser before anything leaves the device. The server receives only the ciphertext and the initialization vector; it never sees the key, so it cannot read the secret or hand it to anyone who asks for it.
A 256-bit AES key and a random 12-byte IV are generated for every send, using WebCrypto.
Authenticated encryption: if the ciphertext is altered, decryption fails instead of returning forged data.
The key travels after the # in the link, the part of a URL browsers never send to the server.
What happens, step by step
- 01You paste the secret. Nothing has been sent yet.
- 02The browser generates an AES-256 key and an IV, then encrypts with AES-GCM.
- 03Only the ciphertext, the IV, and the expiry are stored on the server.
- 04The link is built with the key after the #, so it stays on your machine.
- 05On open, the recipient downloads the ciphertext and decrypts in their browser.
- 06After the first read or at expiry, the record is deleted and the link stops working.
Why the fragment matters
In a URL like https://secureshare.cyberace.tech/s/abc#key, the browser requests only /s/abc. Everything after the # stays on the client: it is not in the request, not in server logs, and not in the Referer header sent to third parties. That is what lets the service store the secret without being able to read it.
Practical consequence: if you lose the full link, the secret is unrecoverable. Nobody can restore it, including us.
Expiry and one-time reads
Every secret carries an expiry, from 10 minutes up to a year, and can burn after the first read. Pick the shortest window that still works for the recipient: a secret that no longer exists cannot leak.
Frequently asked questions
Is it safe to send a password by email?
Not as text in the message body: it stays stored indefinitely across several servers. Send an encrypted, one-time link instead, through a different channel from the file.
What encryption does SecureShare use?
AES-256-GCM through WebCrypto in the browser, with a fresh key and IV per send, and authenticated encryption.
Can you read my secret?
No. We store ciphertext only; the key never reaches the server because it travels in the link fragment.
