Password-Protected Links: How the Encryption Actually Works

You click "add password" on a file link, enter a passphrase, and now only people who know the password can view the file. But what's actually happening under the hood?

The Simple Implementation (Server-Side Check)

The most common implementation: the server stores a hash of the password (using bcrypt or Argon2). When a visitor enters the password, the server hashes their input and compares it to the stored hash. If they match, the server sends the file. The file itself is not encrypted differently — the password just gates server-side access.

This is secure against network attackers (the password check happens server-side over TLS) but not against the platform provider, who can still read the file.

The Stronger Implementation (Client-Side Encryption)

A stronger approach derives an encryption key from the password using a key derivation function (KDF) like PBKDF2 or Argon2. The file is encrypted with this key before being stored. When the recipient enters the password, the key is derived and decryption happens in their browser:

1. Uploader enters password → KDF derives key → file encrypted in browser → ciphertext uploaded
2. Recipient enters password → KDF derives same key → file decrypted in browser → plaintext displayed

In this model, the server never has the key and cannot read the file. This is true zero-knowledge password protection.

Why the Details Matter

The security guarantee you get depends entirely on which model the platform uses. Always check whether password protection is server-enforced (convenience) or cryptographically enforced (genuine privacy).

TiniDrop's password protection prevents unauthorised access to your file links at the server level, combined with Cloudflare's network-layer protections ensuring the connection itself is secure.