Password-protected link

The link names the object. The password is a second factor the sender shares on another channel. HTTP itself, in RFC 9110, has no password field on a URL. The check is application logic in front of the download.

This is not a presigned URL. A presigned URL already carries the credential in the query string. Anyone who can read the URL can download, until it expires. A password link can be forwarded and still fail if the password stayed in a separate mail or a phone call. That split is the point. It is also the failure mode: people paste both into the same chat, and the second factor collapses.

A studio sends `https://send.example/d/91k` to a client and the password `river-44` by SMS. The page hashes the password, checks it, then issues a short download. A colleague who only has the email gets the form and a rejection. A colleague who has both gets the file. If the studio instead puts `river-44` in the query string, the protection is gone the moment the link is logged by a proxy or a browser history. Server logs that store full URLs will store a presigned signature. They should not store a password the user typed, and a careful app keeps that value out of the access log.

Expiry still applies. A password does not extend a dead link, and a living link with a password guessed from a weak word is public in practice. Access control for a known user is a different door: the recipient signs in, and the server checks an account. A password link has no account. Revoking it means deleting the secret or the object, not disabling a user.

Do not confuse this with an encrypted file. A password-protected ZIP checks the password in the recipient's software. The server may have handed out the ciphertext to anyone. A password-protected link checks the password before the bytes leave.