Lo sapevate che le password “lisce” non vanno più di moda? Creare un cocktail di informazioni è sicuramente un metodo più sicuro per proteggere i dati. Vi sono vari modi per fare questo cocktail, quelli che esamineremo in questo articolo si dicono “salted” (aggiunta di sale).
Tutto nasce dal concetto (sensato) che se le password salvate in un qualsiasi sistema, online oppure offline, sono molto semplici, tipo “1234″ oppure “31051969″ (la mia data di nascita), sarà semplice poterle ricavare da parte di criminali informatici (sempre a rompere le scatole questi truffaldini!).
Anche partendo dal presupposto che non si archiviano password in chiaro (se lo fate non me lo dite, per carità, mi viene da starnutire!) ma crittografate in qualche modo, non si è abbastanza certi che in caso di furto del database oppure di attacchi SQL Injection non si rischi di far sapere a malintenzionati le password dei propri utenti o della propria azienda.
Per cercare di migliorare il livello di sicurezza e contemporaneamente aiutare gli utenti sprovveduti che utilizzano password molto semplici (vi ricordo che una password di buon livello è almeno 12 caratteri misti tra numeri, lettere maiuscole e minuscole e simboli), sono state pensate nel tempo diverse vie, vediamone alcune.
Password salate fisse:
Quando si archivia una password, la si memorizza solitamente come hash usando funzioni come MD5, SHA1, ecc. Gli hash vengono poi salvati nel database. Questo modo di procedere è ormai considerato semplicistico e pericoloso. Come abbiamo visto negli articoli precedenti e come vedremo in quelli futuri, ricavare il testo in chiaro da una hash non è poi così complicato.
Per rendere il “reverse” delle password complesso, è possibile aggiungere alle stesse, un valore arbitrario, di tipo misto (lettere + numeri + simboli) prima di archiviarle. Le password così generare risulteranno un misto tra la propria password e quella arbitraria. Ecco cosa intendo:
|
|
<?php function Calcola($password,$ripeti) { $salt = 'abc123!$/'; for($i=0;$i<$ripeti;$i++) { $password = md5($password.$salt); } return $password; } echo md5("password")."\n"; echo Calcola("password",10); ?> |
Verranno visualizzati due hash, il primo è quello calcolato in modo classico con MD5, il secondo viene “salato” o aggiunta una stringa arbitraria $salt e calcolato per 10 volte. Questo tipo di calcolo è particolarmente efficace contro gli attacchi dizionario e le rainbow tables.
Inoltre, rubare il database non ha comunque effetto sul recupero delle password, è necessario sapere il valore di $salt che risiede all’interno del codice PHP anch’esso da “aprire” in modo fraudolento. Quindi, si tratta di due azioni di hackeraggio distinte e non una sola.
Avrete però notato come $salt sia una costante e questo la penalizza dal punto di vista matematico. Anche se però lo rendiamo dinamico non vuol dire che la situazione migliori.
Password salate dinamiche:
Cambiando il valore di $salt in modo dinamico sarà possibile rendere ancora più lungo e complesso il processo di “reverse” della passwod, ecco un primo esempio:
|
|
<?php $password = "password"; $Calcolo = sha1(md5(sha1(md5($password)))); echo $Calcolo; ?> |
In questo caso, il “salt”, è aggiunto direttamente dalla concatenazione di funzioni MD5 ed SHA1. Se ne possono mettere diverse in diverse combinazioni, senza conoscerne la sequenza diventa molto arduo recuperare la password originale.
Il consiglio però è che sarebbe meglio evitare questo genere di concatenazione, quando si passa attraverso una di queste funzioni, il numero di caratteri viene troncato per adeguarlo al calcolo, il passaggio successivo fà uguale e così via. Teoricamente, si aumenta la possibilità di collisione dei termini usati per la password originale.
Oppure possiamo utilizzare una vera variabile pseudo-random tipo:
$salt = microtime();
Da aggiungere alla password. Purtroppo, se si sceglie questa strada, si dovrà memorizzare il valore di $salt da qualche parte. Se si salva nello stesso database e questo viene “aperto” allora questa forma di sicurezza cade.
A questo punto si aprono infinite possibilità, per esempio si potrebbe “salare” le password con la data di registrazione dell’utente oppure con il suo stesso login, sono valori salvati comunque nel database ma non espressamente indicati per il calcolo del’hash. A chi verrebbe in mente di usare un altro campo del database che non riporta indicazioni specifiche relative alla password?
La cosa divertente è che se trovate un bel metodo per “salare” le password, anche utilizzare “1234″ potrebbe diventare una password sicura!
