Bruce Schneier ricorda per l’n-sima volta che, quando richiesto, è il caso di salare gli algoritmi di hash.
Di solito gli algoritmi di hash si usano per rappresentare con un valore gestibile (un numero) qualcosa che o non si vuole scrivere in chiaro (una password, un dato personale) oppure si vuole rappresentare in maniera compatta per una comparazione o ricerca più veloce. Ovviamente il secondo caso non deve essere salato e ci arrivano tutti a capire il motivo.
Spesso la funzione di hash è surgettiva, ma le collisioni sono un male accettabile e, per quanto riguarda le password, può anche andare bene che sia tale, in quanto il rischio che, mettendo una password casuale, si ottenga una collisione è tollerabile.
Il vero problema di una funzione di hash pura e semplice è che è, nei fatti, reversibile. Spesso, anche senza far ricorso alle rainbow table si può trovare una delle stringhe che genero un hash specifico. Un paio d’anni fa ho gestito a livello IT il passaggio di proprietà non proprio amichevole di una ditta. Si sapeva che uno dei vecchi addetti usava sempre la medesima password, ma bisognava sapere velocemente quale. Uno degli applicativi aziendali era scritto in PHP e usava un hash SHA1 per registrare le password. Non vi dico la faccia delle persone quando ho fatto copia e incolla dell’hash su Google ed è venuta fuori la password (non in dizionario).
Per fortuna lo sviluppatore (presente nella scena precedente) non aveva salato le password, in questo modo ho potuto utilizzare Google come rainbow table per ottenere la password in chiaro.
Tra la potenza di calcolo, la capacità di archiviazione e l’interconnessione, oramai usare un algoritmo standard di hash senza sale per nascondere un dato sperando nell’unidirezionalità dell’algoritmo è una decisione da poveri illusi. Tanto vale scrivere il dato in chiaro.
Lascia un commento