Le Password… un falso segreto

Che cosa è un segreto?

Dalla Treccani riporto testuali parole “Ciò che uno nasconde dentro di sé e non rivela (tranne singole e determinate eccezioni) a nessuno” oppure il Devoto-Oli “Fatto, avvenimento o discorso che non deve essere rilevato” o a detta di Georg Simmel “Un segreto noto a due persone non è più tale”. Un segreto è quindi qualcosa che tendenzialmente conosciamo soltanto noi e che non divulghiamo o, se lo facciamo, solo ad una cerchia molto ristretta di persone.

Ma una password è un segreto?

È presente nella nostra mente ma anche memorizzata su un sistema informatico che ogni volta che viene richiesta e digitata, viene controllata da un software che ad ogni accesso la compara con quella presente nella sua base dati per identificare la corretta identità digitale.

Inoltre le password sono difficili da memorizzare, devono essere facilmente immagazzinabili soprattutto dalla nostra mente, figuriamoci più password complesse cambiate con cadenza di tre mesi. Questo ci porta a trascriverle in chiaro in altri supporti magnetici (ad es. PIN del bancomat sul telefono memorizzato sotto falso nome, Post-It sparsi sulla scrivania fino ad arrivare all’intera lista dei nostri account / password ivi compresa URL di accesso su OneDrive). Le nostre password spesso sono “predicibili” perché composte da una serie di informazioni “segrete” o “pubbliche” come date importanti, posti significativi, cose bizzarre che conosciamo bene solo noi e che ci risulta facile ricordare nel tempo.

Ma tutto questo è realmente segreto?

Probabilmente no.

Tipiche debolezze dei nostri segreti sui sistemi informatici

  • Le password sono spesso intellegibili: da un sistemista, dall’addetto della gestione dell’applicazione, da un hacker che effettua una intrusione tramite una o più falle presenti sul sistema.
  • Le password possono essere decifrate: qualora siano state cifrate sul sistema (ad esempio utilizzando algoritmi di hashing o altre forme di cifratura) possono essere decifrate velocemente utilizzando software open-source e hardware di basso costo (cluster di schede GPU di ultima generazione) che consentono bruteforcing o attacchi a dizionario mai visti prima.
  • Carenza di eforcement: molto spesso per agevolare la CX, non si utilizzano tutti gli eforcement per rendere le password complesse. Ovviamente risulta più semplice inserire una password mnemonica rispetto ad una regola che richiede una password di 10 caratteri che vuole intervallata una lettera e un carattere speciale. Purtroppo però la semplicità delle password è direttamente proporzionale alla facilità della sua individuazione e questa è una “coperta corta” da dover gestire.
  • Carenze nel cambio password: una password immagazzinata e mai cambiata, facilita la CX dell’utente ma incrementa il rischio di possibili furti e di compromissione.
  • Password di default: esistono le password degli utenti ma ancora più critiche le password di gestione delle componenti di un sistema. In fase di installazione dei prodotti a supporto di un’applicazione spesso non si effettuano i dovuti cambi password degli account più importanti del sistema, quelli di amministrazione. Questo “perverso costume” noto ai tanti come “password di default”, vanifica molto spesso l’intera sicurezza dei sistemi informatici per carenza di attenzione e di consapevolezza da chi gestisce i delivery e l’esercizio delle nostre applicazioni.

Ma come possiamo proteggerci?

  1. Utilizzando algoritmi di Hash di nuova generazione: i vecchi algoritmi di hash sono oramai obsoleti da anni. Con il vecchio DES si riesce oggi ad effettuare un ciclo di test di attacco a dizionario su 50.000.000 di lemmi in circa 3 secondi arrivando a 30 minuti per SHA512 fino ed arrivare ai 9gg con bcrypt(10) per una singola password. Rimane semplice capire che più è robusto l’algoritmo di hashing più risulta difficile effettuare attacchi a dizionario, pertanto, occorre sempre implementare sistemi che siano in linea con i tempi e con gli sviluppi tecnologici.
  2. Cifrare le tabelle della base dati: A livello applicativo, spesso le password vengono memorizzate sulla tabelle della base dati. Occorre quindi oscurare la visibilità di queste tabelle anche ai sistemisti che accedono all’applicazione anche per la sola manutenzione. Un esempio può essere l’abbinamento della Trasparent Data Encription con la memorizzazione in hash della password. Una doppia cifratura che consentirà anche con il passaggio del tempo di rendere più robusto l’accesso alle password del sistema.
  3. Irrobustire le password policy: Implementando le 4 classi a protezione delle password oltre ad un dizionario (italiano / inglese) per evitare la presenza nelle password di lemmi facilmente identificabili in pattern di attacco specifici o da un attacco a dizionario. Esistono già oggi differenti sistemi operativi e database che implementano in maniera nativa questi vocabolari, ad esempio Red Hat Enterprise Linux, implementa il dizionario sull’autenticazione di sistema già dalla versione 6.
  4. Implementare meccanismi di scadenza ed inattività: una password che rimane sul sistema in eterno è un rischio. Occorre quindi sviluppare funzionalità che consentano di far scadere le password. Inoltre prevedere la possibilità di rendere inattive le sessioni a valle di un timeout rende più sicuri gli account in caso di impersonificazione da parte di terzi.
  5. Form di Login: Le form di login qualora sviluppate male consentono attacchi di SQL Inection molto pervasivi che possono, in casi limite anche portare all’estrazione completa di tutti gli account del sistema comprese le password di accesso. Adottare quindi tecniche di sviluppo sicuro del codice e di scansioni dinamiche del software per scongiurare fenomeni di questo tipo è altamente consigliato e qualora risulti necessario (per la tipologia dei dati trattati) far effettuare un penetration test web per verificare il reale stato del sistema in particolar modo se esposto su internet.

Conclusioni

Le password stanno vivendo momenti difficili da molto tempo e sono ad oggi il primo vettore di attacco informatico che si rileva costantemente nelle attività di controllo. Inoltre questa forma di accesso avrà un ulteriore sprint trainato dalla diffusione degli IoT che usano (e abusano) l’accesso tramite password cablate nei firmware o di “default amministrativo” (come abbiamo visto nel DDoS per la botnet MIRAI). Queste password ovviamente non verranno mai cambiate dagli utenti se non tramite un software di orchestretor che procederà a farlo solo se previsto in fase di design del sistema.

Oggi è ancora presto, ma l’accesso biometrico probabilmente (ma molto lentamente) sostituirà le password aiutandoci anche a rendere più semplice il quotidiano e la CX in quanto un’iride o un volto saranno sempre gli stessi e non cambieranno mai anche avendo più account su sistemi differenti. Oggi possiamo sicuramente fare molto di più per mettere in sicurezza le nostre password, anche introducendo sistemi di OTP che si rivelano efficaci (e di basso costo magari su applicazioni “business-core” che devono essere maggiormente protette) su sistemi dove l’esposizione al rischio e l’appetibilità dei dati risulta elevata.

Passeremo quindi da un segreto ad un qualcosa di fisico che porteremo sempre con noi e detta così potrebbe essere una cosa poco bella.

Non sottovalutiamo mai l’arte dell’hacking che non smetterà mai di stupirci con nuove ed inimmaginate tecniche, magari introducendo ulteriori forme di furto delle credenziali basate sulla riproduzione delle caratteristiche biometriche di un utente (biometric impersonation) per poi rivenderle in formato fisico ed elettronico nel deepweb tramite un nuovo ed inimmaginato marketplace.

A cura di: Massimiliano Brolli

Profilo Autore

Attualmente responsabile delle funzione di monitoraggio dei piani di sicurezza e delle attività di risk Assessment sui sistemi TIM e società partecipate, ha rivestito diversi incarichi manageriali in Telecom Italia e TIIT (Telecom italia information tecnology) spaziando da attività di governance e Audit di sicurezza ad  attività di gestione applicativa di piattaforme centralizzate con un passato nello sviluppo del software in società come IBM, 3inet, Praxi e Bnl oltre a numerose attività di docenza svolte su ambiti come uml, object oriented e differenti framework e linguaggi di programmazione.

Condividi sui Social Network:

Articoli simili