The Password Sharing Problem Nobody Talks About

Last year I needed to share my Netflix password with my parents. They're not technical—they called me asking why the TV wouldn't play anything. My first instinct was to text them the password, but that felt wrong. My texts aren't encrypted, and who knows where that data lives forever.

I ended up writing it on a sticky note and handing it to them when they visited. Not elegant, but it worked.

That's a trivial example. The real problems come when you're sharing credentials for something that actually matters: AWS keys, database passwords, API secrets for work projects.

The Sketchy Ways People Share Passwords Today

I've seen all of these in actual use:

• Email. Classic. Also terrible. Emails live forever in sent folders, archives, and who knows where else. Corporate emails especially are stored on servers you don't control.

• Slack/Teams. Same problem. Messages get archived, searched, backed up. Not where you want your secrets living.

• Spreadsheets. Yes, some teams actually do this. I've seen shared Google Sheets with columns for "password" right next to "account name." No words.

• Password managers' built-in sharing. This is actually the right answer for most teams. 1Password, Bitwarden, etc. have proper sharing with access logs and revocation. If your team isn't using this, start here.

What I Wanted in a Sharing Tool

When I built Secure Share, I had specific use cases in mind:

Quick one-time shares: Sometimes I just need to send someone a password right now and don't want to set up a 1Password vault for them. A URL that self-destructs after being viewed solves this.

No server storage: I didn't want my server to be a password store. The encrypted data should live in the URL fragment (after the #), which never gets sent to the server anyway. The server just serves the page.

No accounts: For the person receiving the link, they shouldn't need to sign up for anything. Click, see password, done.

What "Secure" Actually Means Here

I'm using AES-256-GCM for encryption and PBKDF2 for key derivation. These are standard, well-understood primitives. The implementation is in JavaScript that runs entirely in your browser—nothing happens server-side.

But a caveat: security is only as strong as the weakest link. If someone can guess your encryption key, none of this matters. Use a strong, random key. Don't use a password you've reused elsewhere.

Also: this tool is for relatively low-stakes sharing. If you're sharing enterprise AWS keys with production access, get a proper secret management solution (HashiCorp Vault, AWS Secrets Manager, etc.).

Practical Advice

For personal sharing (streaming services, household accounts):

• Use a password manager with sharing if you already have one
• If not, a quick encrypted URL share works fine
• Just... don't email it

For teams:

• Please use a password manager. I can't stress this enough.
• If you must share via link, use short expiration times
• Track who you've shared what with and revoke when you don't need it anymore

For anything sensitive (bank accounts, production systems):

• Use a password manager with proper access controls
• Consider whether you actually need to share the credential or can use role-based access instead

The sticky note approach, it turns out, is underrated for low-stakes household stuff. Sometimes analog is fine.

Try Secure Share for quick, encrypted credential sharing.