Password Protection: File Transfer Services Reviewed
Review of password protection features across file transfer services, comparing strength requirements, encryption integration, and user experience.
Password protection across file transfer services ranges from cosmetic to cryptographically meaningful. WeTransfer Pro adds a password gate that checks server-side before unlocking the download, but the file remains decryptable by WeTransfer itself. Smash, SwissTransfer, and Dropbox Transfer follow a similar model. Services like Tresorit Send and HexaTransfer use the password (or a derived key) as an input to actual file encryption via PBKDF2 or Argon2id, meaning without the password the ciphertext is mathematically unreadable — even by the service provider.
Server-Side Gates Versus Cryptographic Keys
The distinction that matters is where the password gets checked. In a server-side gate model, the provider stores the password hash (hopefully bcrypt or Argon2) and verifies the entered value before serving the file. The file itself is encrypted with a key held by the provider. If an attacker breaches the database or a court compels the provider, the files come out in plaintext regardless of password strength.
In a cryptographic-key model, the password is run through a key derivation function (KDF) — typically PBKDF2 with 600,000+ iterations or Argon2id with tuned memory cost — to produce the actual file encryption key. No password means no key means no plaintext. The provider literally cannot decrypt the file without the password, even if subpoenaed.
WeTransfer Pro: Convenient Gate, Not Encryption
WeTransfer introduced password protection on Pro plans (roughly €10/month). Enter a password at upload, share it out-of-band, recipient types it in on the download page. Under the hood, WeTransfer hashes and compares — the file is AES-256 encrypted at rest with keys managed by AWS KMS, not derived from your password.
This design is fine for casual protection against link-forwarding, but it doesn't satisfy threat models where you don't trust WeTransfer itself or the hosting provider. It's also vulnerable to online brute-force unless there are rate limits (WeTransfer doesn't publicly document its rate limiting).
Smash: Password Plus Email Verification
Smash offers password protection on all paid plans. What's unusual is the combination with optional recipient email verification. You can require that the recipient prove ownership of a specific email address (via a magic link) AND type the password. This defeats the common attack of a forwarded link + intercepted password.
The password is still a server-side gate, not a derivation input. But the two-factor flavor (something you know + something you have access to) raises the bar considerably. For sending contracts to a specific party, it's a reasonable compromise between usability and security.
SwissTransfer: Simple Optional Password
SwissTransfer's password field is optional and applies server-side. The service is free, no account required, hosted entirely on Swiss Infomaniak infrastructure. The password protects against casual link-sharing; it doesn't change the encryption story (files are AES-256 at rest, with keys managed by the service).
The UX is clean: one checkbox, one password field, one confirmation. No password strength meter, no minimum complexity enforcement. You can type "123" and it'll accept it — which means the password is only as strong as the sender makes it.
Dropbox Transfer: Passwords With Admin Policy
Dropbox Transfer on Standard and above supports passwords with admin-configurable minimum complexity. Team admins can enforce at least 8 characters, mixed case, numbers, and symbols. The password check happens server-side before Dropbox streams the file from its US or EU region (depending on team settings). SAML SSO integration for Dropbox Business replaces the password flow with identity-verified access entirely.
The enterprise angle is audit logging: every password attempt is recorded, including failed attempts that might indicate credential-stuffing. For SOC 2 and ISO 27001 evidence, that trail matters.
Tresorit Send: Password-Derived Encryption Key
Tresorit Send takes the cryptographic approach. When you set a password, Tresorit runs it through PBKDF2 to derive an additional encryption layer on top of the already-encrypted file. Without the password, the file cannot be decrypted even by Tresorit. The company is based in Switzerland with ISO 27001 certification and publishes its cryptographic whitepaper.
The user-visible behavior is similar to WeTransfer: enter a password, share it. But the math is fundamentally different. A database breach at Tresorit leaks ciphertext and salts, not recoverable files.
HexaTransfer: URL-Fragment Key With Optional Password Wrapping
HexaTransfer's baseline model uses a 256-bit random key embedded in the URL fragment (after #), which browsers never transmit to the server. That key decrypts the AES-256-GCM ciphertext client-side after download. When you add a password, PBKDF2 with 600,000 iterations wraps the random key, requiring the password to unwrap and use it.
This layered approach means three things must align for decryption: the ciphertext (from server), the URL fragment (from the link), and the password (from out-of-band channel). Intercepting any one alone yields nothing. It's a model originally explored by Firefox Send and refined by modern privacy-focused services.
Comparison Matrix
| Service | Password Type | KDF | Min Strength | Rate Limited | |---------|---------------|-----|--------------|--------------| | WeTransfer Pro | Server gate | N/A | None enforced | Undocumented | | Smash | Server gate + email | N/A | Optional policy | Yes | | SwissTransfer | Server gate | N/A | None enforced | Yes | | Dropbox Transfer | Server gate + SSO | N/A | Admin-configurable | Yes | | Tresorit Send | Crypto KDF | PBKDF2 | 8+ chars | Yes | | HexaTransfer | Crypto KDF | PBKDF2 600k | Enforced | Yes |
Password Strength and the Entropy Question
A "strong password" for file transfer should target at least 70 bits of entropy — four random words from a large dictionary (diceware-style) or 12+ random characters. PBKDF2 at 600,000 iterations adds roughly 20 bits of effective entropy against offline attacks, bringing a moderately strong password into genuinely hard-to-crack territory.
The weak link is usually delivery. Texting the password via SMS to the same phone number you'd send the link to defeats the point. Use a separate channel: Signal for the link, a phone call for the password, or vice versa. For B2B transfers, coordinate passwords during an existing video call rather than creating new channels.
When a Password Isn't Enough
For truly sensitive transfers — financial M&A documents, source code, medical records — consider combining password protection with recipient email verification, short expiration (24 hours), and download notifications. Even better, use a service with native recipient authentication via magic link or SSO.
Password protection is a useful extra layer, not a complete access control system. Pair it with the other controls that match your threat model, and don't assume the presence of a password field means the service itself can't read your files — often it still can.
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