MooneyGo, vieni qui che dobbiamo parlare!

Venerdì sera, penultima di agosto, famiglia in spiaggia a giocare con le onde, io lavoro tranquillo in terrazza cercando di riempirmi l’anima con il panorama e gli odori della pineta. Bello, bellissimo. Voglio restare qui!

Quasi quasi chiudo e faccio ape

“bidong” 🔔

Ok, dai, vediamo cos’è arrivato in email:   “Comunicazione Importante sulla Sicurezza del Suo Account MooneyGo”

Mai, 🎵
mai scorderai🎶
l'attimo,🎵
la terra che tremò🎶
L'aria si incendiò 🎵
e poi🎶
silenzio…🎵

Dopo un tempo indefinibile, nel bosco ha echeggiato un barbarico “maporcaputtana!”  Lo so, non mi prenderanno all’Institut auf dem Rosenberg. Pazienza.

Dato che sono arrabbiato, sarò breve, sia perché potrei dire cose brutte, sia perché non mi voglio guastare il weekend.

L’email è stata inviata ai sensi dell’art. 34 del GDPR: comunicazione di una violazione dei dati personali all'interessato, un adempimento obbligatorio che si fa solo qualora sussistano rischi elevati per i diritti e le libertà delle persone coinvolte.

Non si fa in altri casi, non è una mail di cortesia, non lo si fa per scrupolo o per gentilezza e nemmeno quando si è semplicemente nel dubbio. Le aziende farebbero di tutto per evitare di inviare questa comunicazione. In breve, le persone coinvolte dal data breach di Mooneygo sono proprio messe male!

Data breach accaduto a Marzo… comunicazione inviata a Agosto. Sono 5 mesi pieni. 150 giorni. Il GDPR prevede che il titolare comunichi “la violazione all'interessato senza ingiustificato ritardo.” Alla faccia della tempestività! Nemmeno Jack Blues avrebbe saputo giustificarsi per un ritardo simile.

Leggendo il testo mi è saltato all’occhio un dettaglio importante. Nella lettera si legge: “In conformità con le indicazioni ricevute dall’Autorità Garante, … bla bla bla”.

Significa che questa comunicazione, decisamente tardiva, ha avuto l’imprimatur del Garante, che è stata specificamente richiesta o, quanto meno, concordata. Fantastico, significa che il Garante avrà dato delle indicazioni su come procedere, evidenziando la necessità di applicare l’art 34 a tutti gli utenti coinvolti e chiedendo di inviare determinati contenuti, pur nel rispetto dei ruoli e lasciando al titolare l’onere di applicare la norma, salvo poi sanzionare eventuali carenze o errori… è il bello della normativa che regola l’attività del Garante e della nostra PA in generale.

Mi domando se, nell’ambito di queste interlocuzioni, il Garante abbia anche richiesto di inserire dei tracker all’interno delle email destinate alle persone travolte dal data breach. Più no che si, direi!

Ma allora, perché diavolo MooneyGo ha inserito nelle email inviate un fantastico tracker di profilazione?

Un tracker di profilazione, come in questo caso, è un pixel trasparente, all'apparenza innocuo, piccolo ed invisibile, ma con un indicatore univoco che cambia in ogni email, uno per ogni utente raggiunto dalla comunicazione. Quando il destinatario apre l’email, visualizzandola, genera una richiesta dati al server che, oltre a trasmettere il piccolo pixel, acquisisce una montagna di informazioni. È il principio di funzionamento dei gestori di mailing list e newsletter con le loro fantastiche e coloratissime analisi e statistiche. Tutta roba lecita... solo che c'è il consenso dell'utente adeguatamente informato e consapevole.

Nelle mail di Mooneygo ho trovato questo:

<img src=3D"https://email.mooneygo.it/tr/p.gif?uid=3F6450809633&mid=3D602=692885&msd=3P8785781058639&s=3GFNLJIILHELOEPJAD&st=3D0" width=3D"1" height==3D"1" alt=3D""/>

(i numeretti sono stati modificati)

Eccolo li: piccolo pixel con indicatore univoco e personale. Bastardo! Questo è il mio pixel, il mio piccolo personalissimo pixel… ed ogni volta che interagirò con lui, mooneygo vedrà tutto ciò che faccio.

Chi sono lo sa già, perché mi ha mandato l’email con il mio pixel personale, ma altri dati che il pixel comunicherà sono riservati e non ho nessuna intenzione di condividerli con cani e porci:

il luogo dove mi trovo (perchè l’indirizzo IP del dispositivo che visualizza l’email permette di ricostruire la località)

il momento in cui apro l’email e, quindi, il fatto che io l’abbia effettivamente aperta (cosa che non sono tenuto a far sapere a nessuno)

quanta volte ho aperto la mail e su quanti dispositivi differenti… e tutti i dati tecnici di quei dispositivi: computer, cellulari, marca e modello, setup grafico e display.

Verrà annotato il fatto che io abbia letto e riletto la comunicazione, che l’abbia inoltrata a qualcun altro oppure se l’ho ricevuta e distrattamente archiviata.

Il pixel cattura anche altre informazioni ma preferisco non dilungarmi. Tanto sul web si trova tutto.

Considerando che queste email sono arrivate in agosto, è ragionevole pensare che, per molti utenti, i dati acquisiti riveleranno anche informazioni ulteriori e meno scontate:

dove erano in vacanza

dove sono ora al lavoro

quando hanno ripreso dalle ferie

Così, tanto per dire alcune cose che quel pixel può far sapere a mooneygo.

Sicuramente Mooneygo non ha alcuna brutta intenzione, quel pixel è scivolato dentro per sbaglio, senza malizia e, sicuramente, senza alcuna volontà di profilare, certamente è stato lo stagista, oppure è una feature del programma in uso, maledetto fornitore… ma sticazzi! La protezione c'è comunque.  Non puoi dire che è un errore, che non hai intenzione di usare quei dati o cose simili: se li hai, allora li devi giustificare, gestire, proteggere. In pratica, la mera disponibilità delle informazioni necessarie per la profilazione qualifica il trattamento e richiede compliance, specialmente quando l'acquisizione è un atto intenzionale e celato agli occhi della persona che ne è vittima.

Mooneygo ora ha un bel problema e dovrà spiegare al Garante Privacy, che sicuramente non ha chiesto di inserire questo tracker, perché diavolo si è sognata di fare profilazione ai danni delle vittime di un data breach, nell’ambito di una comunicazione obbligatoria e ufficiale richiesta dal Garante stesso. 

In più, ed è la cosa più grave che il Garante dovrebbe sanzionare questa profilazione immediatamente poiché, è palese, viene fatta senza alcuna preventiva informativa e senza alcuna base di legittimazione. Già, sorpresa, per fare una cosa del genere, il Garante e la norma richiedono espressamente il CONSENSO degli utenti, cosa che non è stata né richiesta né acquisita da Mooneygo.

Difendersi dall’acquisizione illecita di dati è un diritto, così come lo sarebbe mandare al diavolo chi ci prova. Ecco un consiglio dedicato a chi tiene alla propria privacy e a chi desidera combattere queste forme di violenza:

disattivare la visualizzazione delle immagini nei programmi usati per leggere le email. Si, lo so, ci saranno meno colori… ma tutti questi tracker saranno disattivati e non condivideranno info su di voi.

Per la stessa ragione è meglio evitate di cliccare sul link “Problemi nel visualizzare questa mail? | Aprila nel browser”, anche quello è un link univoco e personalizzato, fatto apposta per te! Anche avendo disabilitato il tracking sul programma di posta, il tracciamento avverrà aprendo quella pagina, che mostrerà la comunicazione nella sua interezza e colore ma, allo stesso tempo, il server acquisirà i parametri identificativi come “tsp”, “custid”, “uid”, etc… il tutto senza avvertire, senza chiedere permesso o conseso.

Vorrei non esprimere giudizi sul contenuto della comunicazione che è certamente stato vagliato anche dall’Autorità Garante… ma c’è un passaggio che mi deprime parecchio: “La Società le suggerisce altresì di procedere a modificare periodicamente le password utilizzate.”   Questa è farina del sacco di Mooneygo, ci scommetto.

Lo dirò con la calma che la pineta mi ispira e la serenità che l’orizzonte del mare mi infonde: ma non dite cazzate, per favore!

Il cambio periodico della password è un errore vecchio come il cucco, partorito in ambito militare (il che è tutto dire) e perpetuato da burocrati che non hanno la minima idea di come funzioni il cervello umano. Cambiare password periodicamente è il modo migliore per fare in modo che le persone utilizzino password banali, pattern ripetitivi con variazioni sequenziali e, in sintesi, indeboliscano il livello di protezione dei propri account. ACN e il Garante Privacy hanno espressamente cancellato il cambio password periodico dalle proprie raccomandazioni e linee guida.

Oltre a questa considerazione, che definirei tecnica, c’e n’è una più generale che non posso tacere: vorrei sapere perché in questa comunicazione fate la morale all’utente su come dovrebbe gestire le proprie password? Caro Mooneygo, siete voi che vi siete fatti fregare i dati, password incluse. Non biasimate gli utenti ed evitate di fare gli splendidi dal momento che avete dimostrato di avere grossi problemi nel proteggere i dati. Se anche il 100% degli utenti avessero utilizzato le migliori password del mondo, la situazione non sarebbe cambiata di una virgola, così come non sarebbe cambiata se gli utenti avessero usato le password più banali. Ribadisco per chiarezza: siete voi ad esservi fatti fregare i dati degli utenti. Lo spiegone pseudotecnico e moralizzatore su come si dovrebbero comporre e custodire le password, per favore e per decenza, rivolgetelo ai vostri tecnici, non agli utenti e non certo a me!

Per quanto riguarda l’aspetto tecnico relativo alla protezione delle password che il comunicato riporta (cifratura, hash, salt, ecc), ho chiesto aiuto a Paolo Dal Checco, esperto di sicurezza informatica e digital forensics. (Grazie Paolo! Santo Subito!)

Il suo responso - che riporto ingralmente - è piuttosto criptico ma, comunque, ben più chiaro del comunicato di Mooneygo:

Onesto l'aver precisato il tipo di algoritmo utilizzato per proteggere le password (non per produrne una "versione crittografata" come indicato nel testo) oltre al "salt", il cost factor e la codifica finale in base64. BCRYPT è un algoritmo di hashing adeguato per memorizzare sul server una versione della password che non permetta a eventuali attaccanti di ottenerla a partire dal suo hash ma nel contempo permette al sistema di verificare se quella inserita dall'utente è corretta.

Le interazioni impiegate (cioè la quantità di calcoli che devono essere fatti per convertire una password nel suo rispettivo valore hash) rallentano i tentativi di brute force e sono sicuramente una cosa buona. L'unico aspetto forse migliorabile è il fatto che nella comunicazione viene indicato l'utilizzo di un "salt fisso da 128 bit «opaco»".

Che cosa è il salt e perché sarebbe meglio fosse variabile e non opaco? Quando l'utente inserisce la password questa viene mescolata con un ulteriore componente (il "salt") e di questo rimescolamento viene prodotto un valore hash, così che un attaccante non si può preparare prima una tabella "password <-> hash" perché non conosce il salt, cioè il "sale" che rende il risultato variabile.

Il salt è sicuramente meglio averlo piuttosto che non averlo, capita ancora oggi di trovare password memorizzate con algoritmi standard tipo MD5 o SHA senza salt, così che il calcolo inverso - quantomeno per password comuni e non particolarmente complesse - diventi talmente facile che esistono online tabelle con miliardi di combinazioni tra password e relativo hash, precalcolate e indicizzate per una ricerca veloce. Un salt fisso però riduce il vantaggio perché una volta noto è possibile procedere con attacchi di forza bruta operando su tutte le password in contemporanea, mentre un salt variabile fa sì che per ogni password debba essere ripetuto l'attacco con tutte le combinazioni possibili. Altro svantaggio del salt fisso è il fatto che due password uguali produrranno lo stesso valore hash, il che può agevolare analisi statistiche e di frequenza, mentre con salt variabile avere due valori hash identici è praticamente impossibile.

Tra l’altro nell’algoritmo BCRYPT il salt è memorizzato in chiaro prima dell’hash della password, quindi il fatto che venga definito nel comunicato “opaco” può significare che la codifica è sempre stata memorizzata senza salt (perché appunto unico ma “opaco”) oppure che invece del salt si sta parlando del “pepper”, cioè di una ulteriore variabile che mescola ulteriormente le cose perché si tratta di un ulteriore segreto applicativo condiviso (diverso dal salt) conservato fuori dal database (talvolta ad es. in sistemi hardware come HSM/KMS) e che si applica oltre al salt per mitigare il furto del solo database (nel quale appunto ci sono sia i salt sia gli hash delle password).

Il fatto che il salt sia "opaco" e quindi non noto cambia poco, in caso di attacco c’è comunque il rischio che gli attaccanti riescano ad avervi accesso, anche se certamente non inserirlo nel DB rende il tutto un po’ più difficile. La "security through obscurity" non è infatti una buona soluzione in linea di principio, può dare un po' di vantaggio in partenza rendendo più difficile l’attacco ma i cattivi recuperano in fretta. Nel caso specifico, non è chiaro se gli attaccanti hanno trovato anche il salt (o il pepper) oppure no, tra l'altro, ma il fatto che il comunicato precisi che "gli autori dell’attacco potrebbero tentare di decifrarle [le password codificate tramite BCRYPT]" e che venga consigliato il cambio della password sugli account nei quali ne fosse stata utilizzata una identica a quella memorizzata nel database fa pensare di sì.

Diversamente, è difficile pensare che gli attaccanti possano provare per ogni hash trovato nel DB anche tutti i possibili 128 bit di salt (sempre se parliamo di “salt” e non di “pepper”) anche nell'ipotesi che possano sfruttare il fatto di conoscere qualche password, ad esempio potrebbero essersi registrati prima dell'attacco e quindi conoscere la loro, così da poterla poi utilizzare per fare un attacco di forza bruta sul salt o sul pepper... ma stiamo parlando già quasi di fantascienza.

Nel caso in cui gli attaccanti non avessero avuto accesso all'unico salt, sicuramente il rischio di brute force delle password sarebbe pressoché nullo e quindi gli utenti potrebbero stare abbastanza tranquilli - a meno appunto di brute force del salt prima - con password nota - e delle altre password poi, ma possiamo per ora considerare questo scenario altamente improbabile. 

Detto questo, il comunicato parla - nelle misure di contenimento e rafforzamento - di "miglioramento degli algoritmi di crittografia", quindi possiamo immaginare che sia stato anche ulteriormente migliorato il sistema con il quale vengono memorizzati sia i dati degli utenti sia le versioni codificate delle password.

Prosit