Autenticazione a due fattori per file: livello di sicurezza extra

L'autenticazione a due fattori per i file abbina qualcosa che il destinatario conosce (una password che deriva una chiave AES-256-GCM via PBKDF2) a qualcosa che possiede (un codice TOTP da Authy, un magic link via email, o una passkey WebAuthn legata al suo dispositivo). Anche se un attaccante dovesse sottrarre la password o intercettare l'URL di download, non riuscirebbe a decifrare il payload senza il secondo fattore. Questo schema neutralizza il forwarding dei link, il credential stuffing e la maggior parte degli attacchi di shoulder-surfing che aggira la protezione singolo-fattore tipica dei servizi stile WeTransfer.

Perché una sola password per link non basta

Un URL di download condiviso è sorprendentemente facile da intercettare. Slack lo espande automaticamente in un'anteprima, Gmail lo archivia per anni, e i proxy aziendali registrano la query string completa. Se la password arriva in una mail separata, spesso entrambi i canali confluiscono nella stessa casella — e una singola violazione di un account Microsoft 365 consegna tutto. Il Verizon DBIR 2025 mostra che il 68% dei furti di credenziali basati su dati coinvolge password riutilizzate. Aggiungere un secondo fattore spezza questa catena, perché il seed TOTP non lascia mai l'app autenticatore del destinatario.

Come funziona il TOTP su un link di download

Il mittente genera un segreto condiviso da 160 bit codificato come stringa base32 e QR code (RFC 6238). Il destinatario lo scansiona con Google Authenticator, 1Password o Yubico Authenticator. Ogni 30 secondi l'app esegue HMAC-SHA1 sul segreto e sul timestamp Unix diviso per 30, troncando il risultato a sei cifre. Quando il destinatario inserisce quel codice, il server verifica la finestra corrente e quella precedente per tollerare la deriva dell'orologio. Solo dopo la validazione del codice il server rilascia il blob cifrato — la chiave di decifratura rimane lato client, derivata dalla password del destinatario.

Magic link email come secondo fattore leggero

Non tutti i destinatari installeranno un'app autenticatore. Un magic link inviato a un indirizzo pre-dichiarato è un'alternativa ragionevole. Il mittente inserisce nome@ospedale.it durante l'upload; il servizio memorizza un hash SHA-256 di quell'indirizzo. Quando il destinatario clicca l'URL di download, il server invia un token casuale da 128 bit valido per 10 minuti via email. Cliccando il token si sblocca la pagina di download dove il destinatario inserisce comunque la password del file. Poiché il token è legato alla sua casella, un link inoltrato a un collega è inutile: il collega non ha mai ricevuto la challenge email.

WebAuthn e passkey per destinatari ricorrenti

Per team che si scambiano file frequentemente — un revisore che riceve mensilmente documentazione di conformità GDPR — le passkey superano i codici. Il destinatario registra una credenziale FIDO2 al primo utilizzo; la chiave privata rimane nel Secure Enclave o in una YubiKey 5C. I download successivi richiedono solo un tocco. Poiché la firma include l'origin, i siti di phishing che fanno proxy della vera pagina di download non possono replicare l'autenticazione. Chrome, Safari 17 e Firefox 122 supportano tutti la conditional UI che mostra il prompt della passkey senza click aggiuntivi.

Proteggere trasferimenti grandi chunk per chunk

Un archivio DICOM da 10 GB o un progetto Adobe Premiere da 4 GB non si adattano al modello di download singolo. Suddividi il payload in chunk da 5 MB, ognuno cifrato con la propria sottochiave derivata dalla chiave master via HKDF (RFC 5869). Prima di servire qualsiasi chunk, il server verifica un token di sessione fresco generato dopo il successo del 2FA. Il token scade dopo 30 minuti, così un download in pausa non può riprendere giorni dopo da un cookie rubato. Questo rispecchia come Signal gestisce i segmenti delle note vocali e come Backblaze B2 applica l'autenticazione server-side agli upload multipart.

Rate limiting, blocchi e la trappola degli attacchi offline

Il TOTP è solo sei cifre, quindi un endpoint ingenuo permette a un attaccante di provare 1.000.000 di combinazioni in pochi secondi. Applica backoff esponenziale dopo tre tentativi sbagliati, blocca il link dopo dieci, e invia un webhook al mittente. Non rivelare agli attaccanti se stanno fallendo su password o codice: restituisci lo stesso errore generico per entrambi. E non fare mai la verifica TOTP lato client; inviare il segreto al browser vanificherebbe l'intero sistema. Valida lato server, in un endpoint protetto da Cloudflare Turnstile o hCaptcha.

Recupero senza indebolire il modello

Il fallimento classico è un destinatario che perde il telefono durante una finestra di trasferimento di 48 ore. Includere un codice di emergenza — una stringa base32 da 20 caratteri stampata alla creazione del link — fornisce un'alternativa senza dipendenza email. Altrettanto importante: scadi il trasferimento comunque una volta scaricato, anche se il secondo fattore non è stato usato. Così un laptop perso contenente il codice di recupero non può essere sfruttato un mese dopo. Alcuni servizi, incluso HexaTransfer, permettono anche al mittente di revocare il link dalla dashboard, eliminando qualsiasi token di sessione attivo.

Cosa costa in termini di esperienza utente

Aggiungere 2FA a un trasferimento da 30 secondi può sembrare eccessivo, quindi calibra in base al rischio. Per un album di foto, non serve. Per un file .psd da 500 MB di un lancio di prodotto, richiedi una password. Per un archivio da 2 GB di dati di accesso soggetto ai sensi dell'Articolo 15 del GDPR, pretendi TOTP più magic link. Un'interfaccia a livelli (pubblico, password, 2FA, passkey) permette ai mittenti di scegliere senza leggere la documentazione. Concorrenti come SwissTransfer espongono un singolo toggle per password; Dropbox Transfer nasconde il 2FA dietro il piano Teams; Smash offre la verifica email ma non il TOTP. Il gap vale la pena di chiuderlo.

Provalo su hexatransfer.com — gratis, senza registrazione, fino a 10 GB.