Tweefactorauthenticatie voor bestanden: extra beveiligingslaag

Tweefactorauthenticatie (2FA) voor bestandsoverdrachten combineert iets wat de ontvanger weet — een wachtwoord dat via PBKDF2 een AES-256-GCM-sleutel afleidt — met iets wat de ontvanger heeft: een TOTP-code uit Authy, een e-mailmagiclink of een WebAuthn-passkey gebonden aan het apparaat. Zelfs als een aanvaller het wachtwoord phisht of de download-URL onderschept, kan hij de payload zonder de tweede factor niet ontsleutelen. Dit patroon weert linkdoorzending, credential stuffing en de meeste shoulder-surfingaanvallen die eenfactorsdeling op WeTransfer-achtige diensten ondermijnen.

Waarom één wachtwoord per link niet volstaat

Een gedeelde download-URL lekt verrassend gemakkelijk. Slack toont er automatisch een voorbeeld van, Gmail archiveert hem zeven jaar lang, en bedrijfsproxy's loggen de volledige querystring. Als het wachtwoord in een apart e-mailbericht staat, zijn beide kanalen vaak dezelfde inbox — zodat één Microsoft 365-inbreuk het bestand prijs geeft. Verizon DBIR 2025 toont dat 68% van credential-gebaseerde datadiefstal hergebruikte wachtwoorden betrof. Een tweede factor doorbreekt die keten, omdat het TOTP-geheim nooit de authenticator-app van de ontvanger verlaat.

Hoe TOTP werkt via een downloadlink

De afzender genereert een 160-bit gedeeld geheim, gecodeerd als base32-string en QR-code (RFC 6238). De ontvanger scant dit met Google Authenticator, 1Password of Yubico Authenticator. Elke 30 seconden voert de app HMAC-SHA1 uit over het geheim en de Unix-timestamp gedeeld door 30, en kapt het resultaat af tot zes cijfers. Bij het invoeren van de code controleert de server het huidige en vorige tijdvenster om klokafwijking op te vangen. Pas nadat de code geldig is bevonden, geeft de server de versleutelde blob vrij — de ontsleutelingssleutel blijft aan de clientkant, afgeleid van het wachtwoord van de ontvanger.

E-mailmagiclinks als lichtgewicht tweede factor

Niet elke ontvanger installeert een authenticator. Een magiclink verzonden naar een vooraf opgegeven adres is een redelijk alternatief. De afzender voert jane@ziekenhuis.nl in bij het uploaden; de dienst slaat een SHA-256-hash van dat adres op. Wanneer Jane de download-URL aanklikt, stuurt de server een 128-bit willekeurige token die 10 minuten geldig is. Door op de token te klikken ontgrendelt ze de downloadpagina, waar ze nog steeds het bestandswachtwoord invoert. Omdat de token aan haar mailbox is gekoppeld, is een link die naar een collega wordt doorgestuurd waardeloos — die collega heeft de e-mailuitdaging nooit ontvangen.

WebAuthn en passkeys voor terugkerende ontvangers

Voor teams die wekelijks bestanden uitwisselen — een accountant die PCI DSS 4.0-bewijs ontvangt, bijvoorbeeld — presteren passkeys beter dan codes. De ontvanger registreert bij het eerste gebruik een FIDO2-credential; de privésleutel blijft in de Secure Enclave of op een YubiKey 5C. Volgende downloads vereisen slechts een aanraking in plaats van opnieuw een TOTP intypen. Omdat de handtekening de herkomst omvat, kunnen phishingsites die de echte downloadpagina proxyen de authenticatie niet herhalen. Chrome, Safari 17 en Firefox 122 ondersteunen allemaal de conditionele UI die de passkey-prompt toont zonder extra klikken.

Grote overdrachten blok voor blok beveiligen

Een DICOM-archief van 10 GB of een Adobe Premiere-project van 4 GB past niet in het model van één doorlopende download. Verdeel de payload in blokken van 5 MB, elk versleuteld met een eigen subsleutel afgeleid van de hoofdsleutel via HKDF (RFC 5869). Voordat een blok wordt aangeboden, controleert de server een vers sessietoken aangemaakt nadat 2FA slaagde. Het token verloopt na 30 minuten, zodat een gepauzeerde download niet dagen later kan worden hervat vanuit een gestolen cookie. Dit spiegelt hoe Signal spraakfragmenten beheert en hoe Backblaze B2 serversijdige authenticatie toepast op meerdelige uploads.

Snelheidsbegrenzing, vergrendelingen en de offline aanvalsval

TOTP bestaat slechts uit zes cijfers, dus een naïef eindpunt laat aanvallers in seconden een miljoen combinaties proberen. Dwing exponentieel uitstel af na drie foute pogingen, vergrendel de link na tien, en stuur de afzender een webhook. Vertel aanvallers niet of ze het wachtwoord of de code fout hadden — geef dezelfde generieke foutmelding voor beide. En verplaats de TOTP-verificatie nooit naar de client; het geheim naar de browser sturen zou het hele doel tenietdoen. Valideer server-side, achter een geharden eindpunt beveiligd met Cloudflare Turnstile of hCaptcha.

Herstel zonder het beveiligingsmodel te verzwakken

Het klassieke probleem is een ontvanger die zijn telefoon verliest tijdens een overdrachtsvenster van 48 uur. Een ingebouwde noodcode — een base32-string van 20 tekens die bij het aanmaken van de link wordt afgedrukt — biedt een uitweg zonder e-mailafhankelijkheid. Evenzo belangrijk: laat de overdracht toch verlopen zodra deze is gedownload, ook als de tweede factor niet werd gebruikt. Zo kan een verloren laptop met de herstelcode later niet als wapen worden ingezet. Sommige diensten, waaronder HexaTransfer, laten de afzender de link ook vanuit een dashboard intrekken, waardoor actieve sessietokens direct ongeldig worden.

Wat dit kost in gebruikservaring

2FA toevoegen aan een overdracht van 30 seconden voelt zwaar, dus stem het af op het risico. Voor een fotoalbum van een verjaardag: sla het over. Voor een .psd-bestand van 500 MB van een productlancering: vereist een wachtwoord. Voor een archief van 2 GB met persoonsgegevens uit een AVG-inzageverzoek: eis TOTP plus een magiclink. Een gelaagde interface (openbaar, wachtwoord, 2FA, passkey) laat afzenders kiezen zonder documentatie te raadplegen. SwissTransfer biedt één wachtwoordschakelaar; Dropbox Transfer verstopt 2FA achter het Teams-abonnement; Smash biedt e-mailverificatie maar geen TOTP. Die kloof is het waard te dichten.

Probeer het op hexatransfer.com — gratis, zonder account, tot 10 GB.