La password è debole: di chi è la colpa?

Il primo giovedì di maggio è il World Password Day, giornata dedicata alla sensibilizzazione degli utenti sull’importanza di alcuni criteri di gestione delle proprie credenziali di accesso a sistemi in rete. Il messaggio è quasi sempre: se le password non ti proteggono, la colpa è tua.

Secondo l’ultima indagine di LastPass, il 91% degli intervistati (non in Italia) usa la stessa password per più account e gli utenti, pur consapevoli del rischio, non fanno nulla per ridurlo. Così come il 42% ritiene più importante avere una password facile da ricordare che una sicura.

Cosa fa un utente quando ha molti account? In Italia non sembrano essere molti ad usare i gestori di password come LastPass. C’è anche il rischio di perdere o di svelare la propria “master password”[1] (e quindi di tutti gli account gestiti) che è superiore al rischio di violazione di alcuni dei propri account dovuto alla rivelazione delle relative chiavi di accesso. Quindi, con tanti account, in teoria dovremmo avere tante password: invece ne usiamo pochissime, forse addirittura una sola, pericolosamente.

Bill Gates è stato ottimista affermando, nel 2004: “There is no doubt that over time, people are going to rely less and less on passwords”. Questo over time si sta prolungando e solo ultimamente Microsoft spinge su soluzioni senza password, con PIN locale o altri metodi.
Negli ultimi anni, ICT Security magazine ha pubblicato interessanti articoli al riguardo.

Massimiliano Brolli[2] analizzava in dettaglio le debolezze delle password e alcune tecniche di protezione consigliando i sistemi biometrici (retina, volto), non senza accennare al fatto che potrebbero essere riprodotti fraudolentemente e quindi non sono la soluzione finale.

Andrea Pasquinucci[3] dedicava spazio alla Federazione di identità che si sta diffondendo: per esempio, “Autenticati con Google o Facebook”, che permette di accedere a una risorsa di un fornitore di servizi utilizzando automaticamente le nostre credenziali Google o Facebook. È utile e pratico anche se implica che Google e Facebook finiscono per conoscere i servizi che frequento. Il problema si sposta sul garantire la sicurezza della password per Google o Facebook. Lo stesso Pasquinucci descriveva nel suo secondo articolo[4] l’autenticazione a fattori multipli e quella con codici “one time” che permettono di aggiungere alla password un secondo passaggio di sicurezza, attraverso una smart-card, una chiavetta, un messaggio ricevuto su smartphone (al quale normalmente accediamo con la nostra impronta digitale) oppure una App di autenticazione. Concludeva con il protocollo FIDO2 e la Security Key, che Google ha già disponibile tra le sue soluzioni di autenticazione come la migliore, ma saggiamente affermava: “È però troppo presto per dichiarare che abbiamo finalmente individuato la strada per abbandonare definitivamente le nostre vecchie e care password”.

Precedentemente, Cesare Gallotti[5] aveva riassunto le nuove specifiche sulle password del 2017 del NIST, l’Istituto statunitense per gli standard, notando il cambio di politica: non più parole complesse con numeri e caratteri speciali, né cambio frequente, ma solamente lunghe almeno 8 caratteri e facili da ricordare, per non doverle conservare scritte da qualche parte, con il rischio di divulgazione. Certamente non devono essere banali, ma devono poter contenere anche spazi ed essere lunghe fino a 64 caratteri. Questo porta a poter utilizzare frasi intere, di facile memorizzazione. Su alcune specifiche Gallotti era critico verso il NIST, ma concludeva invitando a seguirne le regole.

Infine, Emilio Souberan[6] passava in rassegna le politiche di sicurezza informatica previste nel nuovo regolamento europeo sulla privacy, evidenziandone alcune lacune.

In tutto questo panorama non si affronta il problema dell’assenza di segnalazione previa all’utente sulle politiche di gestione e conservazione delle password da parte del sito sul quale ci si vuole registrare. Non si tratta solamente di assicurarsi che il login avvenga tramite https[7], requisito non ancora universalmente adottato, purtroppo. Si tratta di sapere ciò che accade alle nostre credenziali, dopo averle “create”.
Mentre a livello europeo si è insistito molto sulla liceità e sul controllo dei cookies[8] imposti dai siti web, che ci costringe a fare uno o più clic su un’informativa[9] prima di navigare, nessuno sembra aver pensato a obbligare i siti a esplicitare cosa fanno della nostra password: la conservano in chiaro, crittografata, hashed[10], salted[11]?

Facciamo qualche esempio reale che mi è capitato.

C’è un venditore italiano online, al quale si possono anche fornire i dati della carta di credito, che inserisce ancora oggi la password dell’account del cliente in chiaro direttamente nella URL[12], rendendola quindi immediatamente visibile e memorizzata in tutti gli elenchi di pagine visitate da me (cronologia), proxy inclusi.

La Banca Dati Esperti Pubbliche Amministrazioni ha una procedura di recupero password che invia per posta elettronica all’utente la sua password in chiaro, così come la domanda e risposta di sicurezza. Di fronte alla mia protesta per la sua debolezza intrinseca, mi hanno risposto:

• l’amministratore del sistema, così come ogni altro operatore, non ha alcuna possibilità di conoscere la password dell’utente che, come altri dati, è cifrata al momento della creazione: questa modalità non permette di risalire in nessun modo alla password, che viene decrittata in automatico quando un utente usa la funzione di recupero;
• le password vengono inviate in chiaro solo in occasione della prima iscrizione, del loro aggiornamento da parte dell’utente e in caso di recupero delle credenziali: si tratta di una scelta deliberata per agevolare gli utenti, nella chiara consapevolezza che le modalità di conservazione della password dipendono dal buon senso di ciascun utente e non sono governabili a distanza, potendo solo semmai segnalare orientamenti corretti.
• Si evidenzia, infine, che, proprio allo scopo di tutelare al meglio la privacy, gli utenti iscritti alla Banca Dati sono tenuti a rinnovare la password ogni 6 mesi per poter riaccedere alla propria pagina personale.

Decrittare in automatico vuol dire che il sistema conserva la password cifrata e non il suo hash. Chiunque ha accesso al sistema con privilegi alti può eseguire la funzione di decifratura: non è quindi vero che l’amministratore non può conoscerla. Inoltre qualsiasi amministratore di sistema ha accesso alla posta elettronica inviata e può leggere il messaggio che contiene in chiaro password e risposta di sicurezza. Rimandare il problema al buon senso dell’utente è uno scaricabarile: ancora una volta si dà la colpa a chi accede e non a chi gestisce. L’obbligo del cambio ogni 6 mesi in questo caso aumenta i rischi, perché si moltiplicano i messaggi con la password in chiaro: almeno due all’anno a testa.

Tornando alle specifiche NIST, già in una bozza del 2009 si leggeva che non serve cambiare password con frequenza: se la cambiavo ogni sei mesi invece che ogni anno, i delinquenti dovevano semplicemente duplicare gli sforzi. In uno degli scenari illustrati si aggiungeva che, se invece usavo caratteri speciali oltre alle semplici lettere, allungavo da 12 minuti a 2 ore circa il tempo per violarla, mentre se da 8 caratteri di lunghezza portavo la password a 12, allungavo di 500 anni il tempo necessario.

Ancora un esempio con le specifiche della password di un sito importante a cui accedo abitualmente:

• deve essere lunga almeno 8 caratteri
• deve contenere almeno una lettera (porre attenzione alle maiuscole e minuscole che sono considerate differenti!)
• deve contenere almeno un carattere numerico
• deve contenere almeno un carattere speciale tra i seguenti: !”#%&'()*+,-./:;<=>?@|
• deve essere diversa da una delle ultime 3 password.

Le specifiche apparentemente rigorose sono del tutto vanificate dalla prima che dà un vantaggio enorme a chi vuole decifrarla: si riducono infatti notevolmente le combinazioni possibili se so già quanto è lunga la password.

La password – o meglio il suo hash – del mio account LinkedIn, insieme ad altri 6 milioni, fu rubata nel 2012 quando quell’azienda fu oggetto di un attacco. Era di 12 caratteri, includendo numeri e caratteri speciali: più che robusta, secondo gli standard dell’epoca. Ma è stata decifrata. C’è voluto un po’ di tempo e l’anno scorso ho iniziato a ricevere quei messaggi di posta elettronica ricattatori che dicono all’incirca: “Conosco la tua password…”, seguito da richiesta di soldi. Vuol dire che la mia password è stata messa a disposizione o venduta, insieme a quelle di molti altri. Non utilizzo le password di siti importanti in siti diversi: non ho avuto conseguenze su LinkedIn perché l’ho cambiata subito, a differenza di altri che hanno visto compromessi vari altri account per i quali usavano la stessa password. LinkedIn fu accusata di non aver usato il sistema salted per l’hash delle password, avendo facilitato il compito di decifratura attraverso le rainbow tables[13]: come tutti gli altri fornitori di servizi, purtroppo, non aveva dichiarato nulla sul trattamento delle password stesse.

Con il mio account Adobe nel 2013 andò peggio, insieme a milioni di utenti, perché le password non erano neppure in hash, ma semplicemente crittografate: non avevano pubblicato le politiche di gestione.

Ci sono ancora CMS[14] in giro che salvano in chiaro nel database le password dei loro utenti abilitati a effettuare modifiche o pubblicare. Ma non lo sa nessuno se non, forse, l’amministratore che si è dimenticato di attivare la crittografia.

È quindi evidente che manca un tassello importante nella vicenda password: non si possono colpevolizzare solamente gli utenti. A parte i furti nei server dei fornitori e le relative discussioni sulla loro capacità di difesa, non c’è trasparenza su questo tema.

La mia proposta è imporre almeno l’inserimento delle politiche di gestione delle password nell’informativa sul trattamento dei dati personali.
Meglio ancora sarebbe aggiungere uno standard minimo, del tipo salted hash e almeno 12 caratteri di qualsiasi tipo con una black list di password banali (ad esempio, nome e cognome dell’utente).

L’obiezione ovvia è che ci saranno siti che non pubblicheranno nulla o mentiranno nell’illustrare le loro politiche, ma questo vale per qualsiasi obbligo di dichiarazione. Almeno dai fornitori più importanti potremo sapere quali rischi corriamo nel consegnare le nostre chiavi di accesso: non è sempre colpa nostra.

 

Note

[1] Proprio LastPass nel 2015 fu vittima di un attacco e consigliò ai suoi utenti di cambiarla.

[2] www.ictsecuritymagazine.com/articoli/le-password-un-falso-segreto/

[3] www.ictsecuritymagazine.com/articoli/lautenticazione-che-si-evolve-dalla-password-ai-token-u2f/

[4] www.ictsecuritymagazine.com/articoli/lautenticazione-che-si-evolve-dalla-password-ai-token-u2f-parte-2/

[5] www.ictsecuritymagazine.com/articoli/nuove-specifiche-nist-le-password/

[6] www.ictsecuritymagazine.com/articoli/le-policy-sicurezza-informatica-nel-regolamento-europeo-sulla-privacy/

[7] Protocollo che crittografa i dati inviati dall’utente al server che lo autentica.

[8] Meccanismo di memorizzazione di dati relativi alla navigazione dell’utente, al fine del loro riutilizzo.

[9] Quest’obbligo genera il rischio di abituarsi a un clic previo senza nessuna lettura del messaggio, con il pericolo che il pop up sia un malware invece dell’informativa legittima. Quanti utenti rispondono “no” alla memorizzazione dei cookies? È valsa veramente la pena aggiungere questo livello intermedio per accedere a informazioni in rete?

[10] Vuol dire che se ne conserva una trasformazione irreversibile: se conosco un hash, non posso ricavarne la password.

[11] È un sistema di rafforzamento della sicurezza dell’hash: a password uguali corrispondono hash diversi

[12] http://www.xyz.xy/dettagli.php?user=m.crudele&password=Compro!Bene&articolo=150419

[13] Sono più o meno lunghissimi elenchi di hash con la decodifica già fatta.

[14] Content Management Systems che permettono di pubblicare pagine web in modo facilitato e dinamico.

 

Articolo a cura di Michele Crudele