La conservazione delle password: dal caso Ambrosetti ai controlli che i DPO dovrebbero svolgere

---

Il recente Provvedimento dell’Autorità Garante nei confronti di The European House - Ambrosetti S.p.A. (“TEHA”) ha riportato prepotentemente al centro del dibattito aziendale un tema critico: la corretta conservazione delle password. Il Garante, infatti, ha sanzionato severamente l’impiego di funzioni crittografiche obsolete e la custodia in chiaro delle credenziali. Il caso è significativo per tutti i Data Protection Officer, in quanto ci ricorda che i controlli non devono limitarsi alle policy documentali, ma devono comprendere anche la verifica delle misure di sicurezza tecniche adottate. Scopri quali misure il Garante ha imposto a TEHA e quali controlli essenziali includere nel tuo prossimo piano di audit.

---

Algoritmi obsoleti e password in chiaro

Prima di addentrarci nei dettagli del Provvedimento, è fondamentale una breve premessa. I dati dell’ultimo Rapporto Clusit testimoniano un’escalation degli attacchi cyber senza precedenti. Nell’ultimo anno sono stati registrati ben 5.265 incidenti gravi a livello globale, con un drammatico incremento del 48,7% rispetto all’anno precedente. In questo scenario, l’Italia si conferma un bersaglio privilegiato, subendo il 9,6% degli attacchi mondiali.

Il cybercrime agisce sfruttando sistematicamente le vulnerabilità aziendali per trarne profitto. Fra queste, conservare le password in chiaro (o proteggerle con algoritmi obsoleti) equivale a chiudere una porta blindata lasciando le chiavi nella serratura. Quando i database contenenti le credenziali vengono esfiltrati, l’assenza di un hashing robusto permette agli attaccanti di ricostruire le password originali in poco tempo, innescando un effetto domino:

1. accesso indiscriminato a sistemi critici aziendali;
2. sfruttamento dei movimenti laterali nella rete per inoculare malware o ransomware;
3. compromissione di ulteriori account, sia professionali che personali, che utilizzano la stessa password (password reuse).

Il caso Ambrosetti: cosa si rischia ad utilizzare tecniche crittografiche deboli?

Le conseguenze di una gestione tecnica delle credenziali non adeguata trovano concreta esemplificazione nel Provvedimento n. 280 del 17 aprile 2026. Il Garante per la Protezione dei Dati Personali ha accertato l’illiceità dei trattamenti effettuati da The European House - Ambrosetti S.p.A. (“TEHA”) a seguito di un grave data breach, caratterizzato dall’esfiltrazione di un database contenente anagrafiche, indirizzi e-mail e password di accesso di migliaia di interessati. 

Nel corso dell’istruttoria l’Autorità ha accertato che circa 36.000 password degli utenti risultavano conservate completamente in chiaro, mentre le restanti 98.000 erano state sottoposte a password hashing tramite algoritmo MD5, peraltro talvolta senza l’utilizzo di un salt. Il Garante ha fortemente criticato tale approccio, ribadendo come la funzione MD5 risulti “non robusta, in termini crittografici, e il suo utilizzo non rappresenta quindi una misura efficace per proteggere le password degli utenti”. Le vulnerabilità di MD5, infatti, “consentono di risalire, a partire da un digest, alla password che lo ha generato”. 

A nulla sono valse le argomentazioni difensive dell’azienda, la quale ha sostenuto che le credenziali violate afferivano a sistemi applicativi dismessi dal 2022 e che lo sviluppo era stato esternalizzato a fornitori rivelatisi ex post privi di adeguate competenze in ambito di sicurezza applicativa. Tali giustificazioni non hanno esonerato la società: l’Autorità, oltre a sanzionare l’eccessiva conservazione dei dati, ha evidenziato una palese culpa in eligendo del Titolare, ricordando che l’art. 28 del GDPR impone di ricorrere esclusivamente a Responsabili che presentino garanzie sufficienti per mettere in atto misure tecniche e organizzative adeguate. 

Le misure correttive imposte a TEHA

Oltre alla sanzione amministrativa pecuniaria, quantificata in 85.000 euro per la violazione degli articoli 5, 32 e 34 del GDPR, il provvedimento offre ai DPO uno spunto di riflessione cruciale sulla valutazione del rischio post-violazione. 

Inizialmente, TEHA aveva deciso di non notificare il data breach agli interessati, ritenendo che l’incidente non presentasse un rischio elevato e ammettendo, nel corso dell’audizione, che “destavano particolare preoccupazione i possibili rischi reputazionali derivanti dall’invio di detta comunicazione”. L’Autorità ha censurato duramente questa linea difensiva. “l’avere fatto prevalere motivi reputazionali sui diritti di protezione dei dati degli interessati”, si legge nel provvedimento, “rappresenta un elemento di evidente scarso rispetto del principio di accountability”. 

Il Garante ha quindi ribaltato la valutazione del Titolare, qualificando la violazione come “suscettibile di presentare un rischio elevato per i diritti e le libertà delle persone fisiche”. Questa riqualificazione è stata determinata da una molteplicità di fattori, tra cui: 

• La natura dei dati violati (credenziali di autenticazione); 
• Il basso livello di sicurezza garantito dalle funzioni crittografiche utilizzate e la conservazione in chiaro di un numero molto elevato di credenziali;
• La ben nota abitudine degli utenti di utilizzare la medesima password su più sistemi informatici. 

Di conseguenza, l’Autorità ha ingiunto all’azienda l’obbligo di comunicare formalmente la violazione a tutti gli utenti le cui password erano conservate in chiaro o con tecniche non allo stato dell’arte, ai sensi dell’art. 34 del Regolamento. 

Lo stato dell’arte secondo l’Autorità

Il caso Ambrosetti risulta particolarmente significativo per i DPO in relazione ad un aspetto chiave: le misure di sicurezza da applicare alle credenziali. Il provvedimento, infatti, richiama le “Linee Guida Funzioni Crittografiche - Conservazione delle Password” adottate a dicembre 2023 (e aggiornate a maggio 2026) dall’Agenzia per la Cybersicurezza Nazionale, d’intesa con il Garante per la Protezione dei Dati Personali. 

Le Linee Guida chiariscono un principio di sicurezza fondamentale: è fortemente sconsigliato utilizzare funzioni di hash crittografiche generiche per la conservazione delle password. Tali funzioni, infatti, sono progettate per garantire prestazioni elevate in termini di velocità di elaborazione, caratteristica controproducente nel password hashing, poiché riduce significativamente lo sforzo computazionale richiesto agli attaccanti per condurre attacchi brute-force o a dizionario su larga scala. Quando si parla di tecniche di password hashing efficaci servono algoritmi progettati per rallentare le capacità offensive dell’attaccante, garantendo un’alta complessità computazionale e richiedendo una capacità di memoria tale da saturare la RAM in caso di calcoli massivi. 

Le linee guida individuano precise soluzioni tecniche: 

1. L’uso di un salt risulta una condizione necessaria per qualsiasi algoritmo di password hashing, e deve consistere in una stringa casuale di almeno 128 bit per neutralizzare gli attacchi basati sulle cosiddette rainbow tables;
2. Argon2id (insieme a scrypt) risulta l’algoritmo più robusto ed efficiente, e dovrebbe essere prioritario rispetto a qualsiasi altra scelta tecnica;
3. Se l’azienda utilizza il protocollo PBKDF2, quest’ultimo deve garantire una sicurezza adeguata massimizzando il numero di iterazioni: le linee guida suggeriscono almeno 600.000 iterazioni con HMAC-SHA256, oppure 210.000 con HMAC-SHA512. 

I controlli dei DPO, pertanto, dovrebbero estendersi anche alla verifica di questi standard di sicurezza. I titolari del trattamento che adottano misure inadeguate o algoritmi obsoleti (come Bcrypt, nel caso TEHA) dovrebbero essere messi in guardia sulle conseguenze in caso di attacchi e data breach. 

Quali controlli inserire nel piano di audit? Una checklist operativa per i DPO

Il provvedimento Ambrosetti ci insegna che credere di essere conformi solo perché il sistema “funziona” è pericoloso: il primo attacco a segno rischia di far crollare l’intera infrastruttura. Per questo motivo, il piano di audit di ogni DPO dovrebbe includere controlli specifici sulle modalità di conservazione delle password. 

Fra gli elementi fondamentali da verificare in sede di audit vi sono:

• La scelta dell’algoritmo: verificare che non vengano utilizzate funzioni di hash obsolete (es. MD5, SHA-1). Devono essere impiegati esclusivamente algoritmi allo stato dell’arte come Argon2id (soluzione preferibile), scrypt o, in subordine, PBKDF2 con parametri adeguati;
• La complessità computazionale: gli algoritmi di password hashing in uso possiedono una complessità tale per cui sia rapido calcolare un singolo digest, ma eccessivamente dispendioso calcolarne un numero elevato, scoraggiando gli attacchi a forza bruta?;
• Le risorse di memoria impiegate: gli algoritmi scelti richiedono una quantità di memoria (RAM) tale da saturare le risorse del sistema quando molti digest vengono calcolati simultaneamente, rendendo inefficaci i tentativi di attacco massivo?;
• L’utilizzo del salt: ogni password è protetta da un salt generato casualmente, unico per ogni utente e di lunghezza adeguata (minimo 128 bit), per neutralizzare l’efficacia delle rainbow tables?;
• Il censimento dei sistemi: esiste un inventario aggiornato di tutti i database che conservano credenziali? Il caso Ambrosetti dimostra che le password lasciate in sistemi dismessi o non monitorati sono le prime ad essere violate dagli attaccanti;
• La verifica dei fornitori: in caso di esternalizzazione, il contratto prevede clausole chiare sulla responsabilità del fornitore in merito alla protezione dei dati? Le competenze di cybersecurity del fornitore sono state effettivamente verificate prima dell’affidamento?;
• La documentazione: le scelte tecniche in materia crittografica sono documentate, giustificate e periodicamente revisionate nel registro dei trattamenti, nella valutazione dei rischi e, ove applicabile, nella valutazione d’impatto (DPIA)?

 

Abbiamo sviluppato una checklist completa delle verifiche da effettuare, disponibile nella sezione riservata agli associati. Inserire questi controlli nel piano di audit permette ai DPO di avere una visione più completa su rischi di sicurezza e sulle contromisure adottate dall’organizzazione, e al Titolare di proteggere efficacemente le credenziali prima che diventino l’anello debole della propria infrastruttura.