Password link security — what happens when you click

Half of the tutorials about password-protected links start with the sentence that it is an "additional layer of security". And that's where it ends. In my opinion, that is precisely the least important thing one can say about it.

Because a "security layer" explains nothing. It doesn't tell you what happens to that password, who sees it, or when it even makes sense. And those are the only questions worth asking yourself before you click "Add password".

So one by one.

The password on the link is not the same as the padlock on the gate

People imagine that a password closes a link for good. That is not the case. The security of password-protected links works more like a concert ticket: whoever has the ticket, enters. Whoever gives it to someone else, will also let someone in.

That sounds like a flaw. It isn't. You just need to know what this mechanism is for.

Three situations in which it is truly useful:

Price list for premium customers or a document in beta version, before it goes out into the world. Without a password, such a link will sooner or later end up in Google or pass from hand to hand.

Content with an expiration date. Offer valid for Friday only. Conference material exclusively for participants. The password turns the link into a controlled entry — you know that someone received it from you, and didn't just find it by chance.

The second thing that you post fully publicly, but want to keep an eye on. The link may circulate. Without a password, no one will be able to enter anyway.

And now, what this guide was not supposed to omit

You type a password into the form. At that same moment, it disappears. Literally. The fact that you set "tajne123" ceases to exist in a readable form before you even have time to release the button.

What remains in the database? Not the password. A fingerprint of it. Professionally: a hash. A string of characters that matches your password only when someone enters exactly the same thing as you. It does not reveal anything on its own.

I will say it plainly, because it is important: I, the service provider, have no way to read your password. Not because I am being polite. But because there is physically nothing to read. If someone hacked into the database, they would take away a stack of these fingerprints and that's it.

The algorithm that calculates this is intentionally slow. I know that "slow" sounds like a complaint, but it is an advantage. The point is that someone who stole the database would have to spend an absurdly long time guessing a single password. We are talking about years, not seconds.

Click from the other side

Someone gets your link and clicks. Instead of reaching the target immediately, they see a screen: "this link is password protected", an input field, a button.

It enters. The server compares what was entered with the saved fingerprint. Does it match? It receives a session token valid for a day. For the next 24 hours, it returns to the link without typing anything. It doesn't have to remember, it doesn't have to struggle.

Doesn't match? Error. Five mistakes from the same IP address and entry is blocked for five minutes. A bot trying to hammer through passwords one by one will hit a wall.

What is simply not here

We do not store passwords in plain text. Nowhere. Not even in logs, which I check when searching for errors.

We do not send passwords via email. This means that if someone forgets their password, I will not send it to them because I do not know it. You must send it yourself, using the same channel as before.

And we do not pass passwords to the outside. No analytics, no marketing, no AB touches this data. (This is actually a rule that applies throughout all of cutty.dev, not just here.)

Two habits that make a difference

First: do not make up a password from your head. Company name plus year of establishment is a gift for everyone who knows you. A browser generator will spit out something better in a second.

Second, more important: do not send the password through the same channel as the link. Did the link go via email? Send the password via SMS. Or vice versa. The point is that compromising one inbox does not give anyone the complete set.

A small detail that few people know: you can create several links leading to the same address, but with different passwords. You give access to five people, each with a separate link. One needs to say goodbye? You block her link, and the rest won't even notice.

You will change the password without creating a new link. Panel, "Edit", new password. Note: all active 24-hour sessions expire immediately. Everyone must enter the password anew.

A boundary worth knowing in advance

Let's get back to the concert ticket. The password protects against search engines and against accidental guests. It does not protect against someone who knows the password and decides to share it with the world.

If your scenario sounds like "this is meant to be seen by exactly this one person and no one else," then a password is not enough. Here you need accounts, login, authorization. A different league, a different problem.

But hands up, how often do you really have such a scenario? In my experience, rarely. In the vast majority of cases, it is simply about "I don't want someone from the street to end up here." And that phrase is more than enough.

If you want to see how it looks from the inside — when creating a link, expand "Advanced options" and check "Add password". The rest happens automatically.