File sharing

Password-protected file sharing, and when it helps

A password on a share link solves one specific problem: forwarding. Here is what it protects against, what it does not, and how to use it properly.

, Senior Software Engineer, dosya.dev team 5 min read

A share link is a URL, and URLs travel. They get forwarded, pasted into group chats, quoted in email threads that grow new recipients, and saved in browser histories on shared machines.

A password changes the rule from “whoever has the link” to “whoever has the link and the password”. That is a narrow improvement, and knowing exactly how narrow is what makes it useful.

The problem it actually solves

An unprotected link grants access to anyone holding it. That is a feature when you are sending a portfolio and a liability when you are sending a contract.

The realistic threat is not an attacker guessing URLs - share tokens are long random strings and guessing them is not practical. The realistic threat is onward transmission: your recipient forwards the mail to a colleague, the thread gets included in a larger reply-all, the link ends up in a shared inbox, or someone pastes it into a team chat where forty people can see it.

A password means none of those recipients can act on it. That is the entire benefit, and for a great many situations it is enough.

What it does not solve

It is not encryption of the content. It is an access check in front of a download. If your concern is that the storage itself should not be readable, that is a different mechanism entirely, with much larger trade-offs - what zero-knowledge means covers it.

It fails completely if the password travels with the link. Sending both in the same email defeats the whole mechanism: anyone who receives the forwarded message has both halves. You have added a step for your recipient and nothing else. Send the password by a different channel - a message, a call, or something the recipient already knows and you never transmit at all.

It does not expire. A password shared once tends to circulate, and unlike a person, a password does not forget. This is why it pairs with an expiry date rather than replacing one.

It does not tell you who opened the file. Everyone shares one secret, so the access log says “someone with the password”, which is not an answer if the question is which of six people leaked a document.

Choosing the right level

Most sharing needs one of three levels, and picking the lightest that works matters - every extra step is somewhere a legitimate recipient gets stuck and emails you instead.

An open link. Right for anything you would be comfortable seeing indexed by a search engine: portfolios, public documents, press material, published reports.

A password. Right when the audience is small and known, the material is sensitive-ish rather than sensitive, and the recipients have no account and cannot be asked to create one. This describes most client work.

Restricted to named email addresses. Stronger, because access is tied to identity rather than a shared secret. Nothing can be forwarded usefully, and the record shows which person opened what. Right for anything with legal, financial or personal-data consequences. Our guide to sharing sensitive documents covers when to reach for this.

Practical advice

Use a password you have not used elsewhere. You are about to send it over a channel you do not fully control, so it should be worthless if intercepted.

Do not derive it from the content. invoice2026, smith-contract and projectX protect nothing against anyone who knows the context, which is exactly the population you are worried about.

Make it typeable. Recipients enter this by hand, often on a phone. Four random words beat a 20-character string of symbols: comparable strength, far fewer support messages.

Set an expiry alongside it. The realistic failure mode is a leaked password, and a leak matters far less when the link stops working on Friday.

Send it separately, and say you are doing so. A short “password to follow by text” line prevents the reply asking for it.

A worked example

You are sending a signed contract to a client contact you have emailed before.

What most people do: attach the PDF, send it. It now lives permanently in their mailbox, your sent folder, and both organisations’ mail backups, and it gets forwarded to their legal team inside a thread you cannot see.

What takes thirty seconds longer: upload it, set the link to expire in 21 days, add a password, and send the link by email with “password by text to follow”. Then send four random words by text.

The client opens it in a minute. If the email is forwarded to their legal team, that is fine - the client forwards the password too, and you have lost nothing you were protecting against, because the risk was never their legal team. What you have protected against is the thread being included in a larger reply-all three weeks later, and the link still working next year.

The asymmetry is the point. The cost is thirty seconds of yours. The benefit is that the failure mode - a document about someone’s contract terms sitting behind a permanently live URL - simply cannot happen.

Where this fits in a wider habit

Password protection is one rung on a ladder, and the rung below it - setting an expiry - is the one worth making automatic. Most exposure does not come from a determined adversary; it comes from links nobody revisited, still live years later, still granting access to a document about someone who is no longer a client.

For material that genuinely matters, combine the controls: restrict who can open it, put a date on it, and keep a record of who did. Each one is cheap. The combination is what makes an accidental forward a non-event rather than an incident.