Password-Protected File Transfer: Secure Your Shared Files
Add password protection to file transfers for an extra security layer. Learn how password-derived encryption works and best practices for strong passwords.
Password-protected file transfer means the recipient can't decrypt the payload without a secret the sender chose. The password isn't just a login gate — it's an input to PBKDF2-HMAC-SHA256 (or Argon2id) that derives the AES-256-GCM key used to encrypt the bytes. Without it, the ciphertext on the server is noise. This differs sharply from "password-gated" transfer tools that store files in plaintext and merely check the password at the HTTP layer. Real password protection ties the password to the cryptography itself.
The difference between gating and deriving
Most consumer file-sharing platforms before 2020 used password gating. You uploaded a .pdf, the server stored it on S3, and a Rails controller checked the submitted password against a bcrypt hash before handing over the file. An admin with database access or a subpoena saw everything. Password-derived encryption flips that: the browser runs PBKDF2 with 600,000 iterations (OWASP 2023 baseline), stretches the password into a 256-bit key, and encrypts before upload. The server holds ciphertext and a random salt. No password, no key, no file. Firefox Send used this model before Mozilla shut it down in 2020.
Choosing between PBKDF2 and Argon2id
PBKDF2 is the workhorse — it ships in the Web Crypto API, runs everywhere, and resists brute force at high iteration counts. Argon2id is newer and better: memory-hard, so GPU attackers can't crank through rainbow tables cheaply. The catch is browser support. Native Argon2 isn't in Web Crypto yet, so services implement it via libsodium.js, which adds about 180 KB to the bundle. For a 10 GB transfer where the bottleneck is the upload anyway, the tradeoff favors Argon2id with m=64MB, t=3, p=1. For a 20 MB attachment, PBKDF2 at 600k iterations finishes in 400 ms on a mid-range phone.
What makes a password strong enough
A 12-character mix of upper, lower, digits, and symbols reaches roughly 78 bits of entropy — plenty against 2026-era offline attacks on Argon2id. A four-word Diceware passphrase (correcthorsebatterystaple style) hits 51 bits and is easier to read over the phone. Avoid short passwords even with KDF stretching; an attacker with a stolen ciphertext and salt can run PBKDF2 on an RTX 5090 at 20 million guesses per second. Six-character passwords fall in minutes. Length beats complexity. Shout it at every user who tries "Summer2026!".
Sharing the password without defeating the purpose
Emailing the file link and the password in the same thread defeats everything. Attackers who own the inbox own both. Split the channels: send the link by email, the password by SMS or Signal. Even better, use a one-time secret service like 1Password's Psst! or an in-app Slack direct message that can't be forwarded screenshot-free. For recurring recipients, agree on a password derivation scheme out of band (say, "month name plus project ID") so nothing sensitive travels the wire at all.
Salt, nonce, and why they're not the password
Three pieces travel alongside the ciphertext: a salt for the KDF (16 bytes), a nonce for GCM (12 bytes), and an authentication tag (16 bytes). None of them need to stay secret — they just need to be unique per transfer. Reusing a nonce with the same key is catastrophic in GCM: it leaks the XOR of plaintexts. Cryptographically random generation via crypto.getRandomValues() handles this, and the salt gets stored in the file metadata header. The password is the only secret; everything else travels with the ciphertext.
Protecting against client-side tampering
A malicious browser extension can read the password as the user types it. Mitigate with Content Security Policy headers that forbid inline scripts and external connections (connect-src 'self'), Subresource Integrity on all bundled JavaScript, and a strict Referrer-Policy so referrers don't leak to analytics. Audit the wasm bundle with subresource hashes in the manifest. None of this stops a compromised OS, but it raises the bar beyond casual skimmers. HexaTransfer publishes its SHA-384 hashes so power users can verify the loaded bundle matches the source repository.
Resuming interrupted downloads without leaking the key
For a 5 GB .iso file the download may span hours. If the tab closes, resume should work without retyping the password. Store the derived key in SessionStorage (never LocalStorage — it persists across restarts) and wipe it when the download completes or the tab closes. For the chunk-by-chunk model, each 5 MB block gets its own HKDF subkey derived from the master; this way a paused session restart only exposes the current chunk's subkey, not the root. Smash and SwissTransfer both support range requests but handle key material differently.
When password protection isn't enough
Password alone doesn't stop an authorized recipient from re-sharing the file. Once Jane decrypts the .docx, she can forward it anywhere. For true containment, combine passwords with DRM-style restrictions: single-download links, IP-bound access, or short expiry windows (15 minutes for a PCI DSS 4.0 evidence package). For GDPR Article 32 compliance, log who accessed what and when. Password protection is a floor, not a ceiling — it raises the cost of casual interception without solving the insider-threat problem.
Try it at hexatransfer.com — free, no account, 10 GB max.
Send large files securely with end-to-end encryption
Transfer files up to 10 GB for free with end-to-end encryption. No account required. Your files are encrypted in your browser before upload — no one else can read them.
Send a file