Trasferimento file protetto da password: proteggi i tuoi file

Il trasferimento file protetto da password significa che il destinatario non può decifrare il payload senza il segreto scelto dal mittente. La password non è solo un cancello di accesso — è l'input di PBKDF2-HMAC-SHA256 (o Argon2id) che deriva la chiave AES-256-GCM usata per cifrare i byte. Senza di essa, il ciphertext sul server è rumore. Questo differisce nettamente dai tool di trasferimento "protetti da password" che conservano i file in chiaro e verificano la password solo a livello HTTP. La vera protezione con password lega la password alla crittografia stessa.

La differenza tra blocco e derivazione

La maggior parte delle piattaforme di file sharing prima del 2020 usava il blocco da password. Caricavi un .pdf, il server lo conservava su S3, e un controller verificava la password inviata rispetto a un hash bcrypt prima di consegnare il file. Un amministratore con accesso al database o una richiesta legale vedeva tutto. La crittografia derivata dalla password ribalta questo: il browser esegue PBKDF2 con 600.000 iterazioni (baseline OWASP 2023), prolunga la password in una chiave da 256 bit e cifra prima dell'upload. Il server conserva ciphertext e un salt casuale. Senza password, nessuna chiave, nessun file. Firefox Send usava questo modello prima che Mozilla lo chiudesse nel 2020.

Scegliere tra PBKDF2 e Argon2id

PBKDF2 è il cavallo di battaglia: è integrato nella Web Crypto API, gira ovunque e resiste alla forza bruta ad alto numero di iterazioni. Argon2id è più recente e migliore: memory-hard, quindi gli attaccanti con GPU non possono scorrere rainbow table a buon prezzo. Il problema è il supporto browser. Argon2 nativo non è ancora in Web Crypto, quindi i servizi lo implementano via libsodium.js, aggiungendo circa 180 KB al bundle. Per un trasferimento da 10 GB dove il collo di bottiglia è comunque l'upload, il compromesso favorisce Argon2id con m=64 MB, t=3, p=1. Per un allegato da 20 MB, PBKDF2 a 600.000 iterazioni termina in 400 ms su un telefono di fascia media.

Cosa rende una password abbastanza forte

Un mix di 12 caratteri tra maiuscole, minuscole, cifre e simboli raggiunge circa 78 bit di entropia — più che sufficiente contro gli attacchi offline del 2026 su Argon2id. Una passphrase Diceware a quattro parole (del tipo cavallo-corretto-batteria-graffetta) raggiunge 51 bit ed è più facile da leggere al telefono. Evita le password corte anche con KDF stretching: un attaccante con un ciphertext rubato e il salt può girare PBKDF2 su una RTX 5090 a 20 milioni di tentativi al secondo. Le password di sei caratteri cadono in pochi minuti. Insistilo con ogni utente che prova "Estate2026!".

Condividere la password senza vanificare la protezione

Mandare il link al file e la password nella stessa email vanifica tutto. Un attaccante che controlla la casella ottiene entrambi. Separa i canali: invia il link via email, la password via SMS o Signal. Ancora meglio, usa un servizio one-time secret come 1Password Psst! o un messaggio Slack diretto che non può essere inoltrato senza screenshot. Per destinatari ricorrenti, concordate uno schema di derivazione della password fuori banda (es. "mese + ID progetto") così nessun dato sensibile viaggia mai sulla rete.

Salt, nonce e perché non sono la password

Tre elementi viaggiano insieme al ciphertext: un salt per il KDF (16 byte), un nonce per GCM (12 byte), e un tag di autenticazione (16 byte). Nessuno di questi deve restare segreto — devono solo essere univoci per ogni trasferimento. Riutilizzare un nonce con la stessa chiave è catastrofico in GCM: rivela lo XOR dei testi in chiaro. La generazione crittograficamente casuale via crypto.getRandomValues() gestisce questo, e il salt viene conservato nell'header dei metadati del file. La password è l'unico segreto; tutto il resto viaggia con il ciphertext.

Proteggere contro la manomissione lato client

Un'estensione browser malevola può leggere la password mentre l'utente la digita. Mitigazioni: header Content Security Policy che vietano script inline e connessioni esterne (connect-src 'self'), Subresource Integrity su tutto il JavaScript bundled, e una Referrer-Policy restrittiva così i referrer non trapelano agli analytics. Verifica il bundle WASM con hash di sottorisorsa nel manifest. Nessuna di queste misure ferma un OS compromesso, ma alzano l'asticella oltre i raccoglitori casuali.

Riprendere i download interrotti senza esporre la chiave

Per un file .iso da 5 GB il download può richiedere ore. Se la tab si chiude, la ripresa deve funzionare senza reinserire la password. Conserva la chiave derivata in SessionStorage (mai LocalStorage — persiste tra i riavvii) e cancellala quando il download completa o la tab si chiude. Per il modello chunk-by-chunk, ogni blocco da 5 MB riceve la propria sottochiave HKDF derivata dalla chiave master; così un riavvio di sessione in pausa espone solo la sottochiave del chunk corrente, non la radice. Smash e SwissTransfer supportano entrambi le range request ma gestiscono il materiale crittografico in modo diverso.

Quando la protezione con password non basta

La sola password non impedisce a un destinatario autorizzato di ricondividere il file. Una volta che la destinataria decifra il .docx, può inviarlo ovunque. Per un vero contenimento, combina le password con restrizioni in stile DRM: link a download singolo, accesso vincolato all'IP, o finestre di scadenza brevi (15 minuti per un pacchetto di evidenze PCI DSS 4.0). Per la conformità all'Articolo 32 del GDPR, registra chi ha avuto accesso a cosa e quando. La protezione con password è un punto di partenza, non un punto di arrivo — aumenta il costo dell'intercettazione casuale senza risolvere il problema della minaccia interna.

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