Password-protected links: when you need them and how to set up
Sometimes passwords help. Sometimes they just get in the way.
Let's figure this out without fluff.
Basic idea is simple. We encrypt your text in browser. Key stays in URL after # symbol. Server sees only encrypted gibberish. That's standard.
Password on link adds extra protection on top. Sounds logical, but there are catches.
What this is
Take regular one-time link. Add password to it. Done.
Nobody opens your secret without the password. Even if they steal the link itself.
Only you and recipient know password. Server doesn't see it — we still encrypt locally. Decryption key sits in #fragment, as usual.
I recently sent access to colleague. Then remembered — he has shared screen open in meeting room. Quickly enabled password on link. Now even if someone saw URL in browser history, they get nothing. Small thing, but I slept better.
When password really helps
Shared devices
Working from shared computer? Recipient reads email on someone else's laptop? Password helps. Even if someone sees link in browser history, can't open the secret.
Extra sensitive stuff
Bank details, prod keys, personal documents. Better safe than sorry here. Set both password and one-view limit, plus short expiry.
Long delivery
Sent link, but reply comes tomorrow or next week. Password adds protection during that time. Just don't set expiry to month "just in case". Bad idea.
Corporate rules
Company says "secrets only through password-protected links". Okay, do that. Just don't turn it into bureaucracy.
By the way, recently saw employee set password "1111". Asked why, he said "good enough, right?". Um, no. Not good enough.
When password gets in the way
Self-destruct links
Recipient online? Will read immediately? One view is enough.
Password might annoy people. They'll start sending secrets through regular chats. That's worse than link without password.
Low risk stuff
Sometimes you're sharing something not too important. Delivery window is small — half hour max. One-time link handles this fine.
No second channel
Most common mistake. No way to send password separately, so they write it next to link. "Link: xxx, password: 1234".
Doesn't work.
Better no password than password in same message. If you're unsure — still use password, but find second channel. Phone call, different messenger, in person. However this takes effort.
How to do it right
Pick link type first. Need quick handoff? Self-destruct. Recipient replies in day or two? Temporary with short expiry.
Generate password
Not "1111" or "password123". Get something random. Even short mix of letters and numbers works, just make it unguessable.
Separate channels
Link goes via email. Password via messenger. Or reverse.
Main rule: not same place.
Set limits
One view almost always enough. If person might need to try twice, set 2-3. More only if you know exactly why.
Expiry: 10 minutes to day. Rarely longer.
Explain to recipient
"Link is one-time, works until evening. Password coming via telegram."
Short and clear.
We once transferred access to auditors via corporate email. Long approvals, many people in copy. Password on link plus day expiry solved the problem. Bit more hassle, but slept peacefully.
Common mistakes
Password next to link
Most frequent one. "Here's link, here's password".
Doesn't work.
Always separate channels. Even if lazy. Especially if lazy.
Expiry set to month "just in case"
Why? After day context is forgotten, after week nobody remembers what this was. Set real deadline — day max for most cases.
One link for the team
Created link, sent to five people. First one opened — others get "link unavailable".
Generate separate for each person. Yes, takes longer. But works.
Screenshots
"Let's screenshot and send". No, don't.
Screenshot doesn't burn. Stays in gallery, chats, cloud.
Password "12345"
Seriously? 6-8 random characters take one second, protect much better.
About messenger previews. Ours are safe — bots don't see content. But better not write password in same message as link. Good habit.
What to pick in different situations
Recipient online right now → Self-destruct link (password optional) → Read — burned. Quick and simple.
Different time zones, reply tomorrow → Temporary link + password + 1 view → Time to think, but with protection.
Writing in shared work chat → Any link + password required → Someone might accidentally see link in history.
Document workflow, approvals → Temporary link + 1 view → Long approval chains, but with clear deadline.
Main thing — don't complicate without need. If people start bypassing your system and sending secrets through regular chats, you lost. Simplicity often beats perfect security.
How to explain to recipient
People often don't understand what to do with one-time link. So explain briefly:
"Link is one-time, works until evening." "Password coming via telegram." "Don't forward to anyone." "If doesn't open, write — I'll make new one."
That's it. Such notes save half hour of explanations. Tested.
Common questions
Do I always need password?
Not always. For quick transfers might get in way. But if doubts — better set it.
What's more important: password or view limit?
Depends. Limit cuts risk time. Password protects in transit. Together is best.
Made mistake with expiry, what now?
Nothing terrible. Expired — create new one. Normal thing.
Where to store password?
Nowhere. Used — deleted. Along with message.
Short version
Need speed? Self-destruct link. Need time? Temporary with short expiry. Shared device access? Add password.
Separate channels. Set one-view limit.
Done.
Secure, simple, works. If need step-by-step guide — there's separate manual. Want to try right away — here's link generator.