Un pizzico di sale

Saline / SaltworksBruce 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.

Autore: Luigi Rosa

Consulente IT, sviluppatore, SysAdmin, cazzaro, e, ovviamente, geek.

10 pensieri riguardo “Un pizzico di sale”

  1. Notevole l’idea di cercarlo su google. Non pensavo che google avesse indicizzato (per caso, chiaramente) cosi` tanti dati di quel tipo (testo in chiaro e hash) per riuscire ad azzeccare una password che per di piu` non e` in dizionario. Anche perche` almeno in teoria google non dovrebbe avere occasione di vedere, nel web, tanti casi di coppia testo-hash, escluse ovviamente le rainbow tables fatte apposta per quello scopo.

  2. Non credo che la rainbow table trovata da Luigi fosse li` per caso. Qualcuno l’ha fatta indicizzare apposta a Google.

    Ho cercato l’hash SHA-1 di “pippo” e l’ho trovato su almeno 2 siti:
    http://md5.znaet.org/md5/0c88028bf3aa6a6a143ed846f2be1ea4
    http://md5-database.org/sha1/pippo

    Aggiungo una precisazione importantissima: se si usa un hash per motivi di sicurezza (e non di indicizzazione) assolutamente NON bisogna piu` usare SHA1. E` stato violato. GAME OVER.

    Come ricorda sempre Bruce Schneier, gli attacchi crittografici possono solo migliorare col tempo.

    Va benissimo come esempio di come funziona un hash. Ma non si deve usare nel mondo reale (cosi` come non si devono piu` usare MD-5 e simili).

    Aggiungo che praticamente tutte le funzioni di hash sono suriettive. Rientra nella loro natura.
    Quando sono usate per indicizzazione, basta tener conto delle collisioni (che sicuramente ci saranno) e gestirle.
    Quando sono usate per sicurezza, le collisioni sono il principale vettore d’attacco. Il “sale” e` il modo di rendere molto piu` arduo questo attacco.

    Un buon algoritmo di hash riduce il numero di collisioni, ma e` impossibile azzerarle per il paradosso dei compleanni. Un cattivo algoritmo di hash ne avra` tante… lo so bene perche’ a 14 anni la prima volta che provai ad implementare una tabella hash inventai un algoritmo brutale che di collisioni ne aveva davvero tante. Ma le gestivo bene, dunque il tutto era ragionevolmente efficiente.

  3. L’argomento è molto interessante, ma ho fatto un paio di prove con due password non proprio geniali: “scatolachiusa” e “pippolesso” e in entrambi i casi Google non ha trovato un bel niente. Ho usato MD5.

    @Luigi: sei in grado di produrre un esempio di password non in dizionario che sia individuabile con questo metodo? (tra parentesi, non è una sfida, è interessamento puro all’argomento)

    Grazie.

    1. Ho fatto altre due prove: closedbox e secretwork. Con la prima ha funzionato (Google l’ha trovata), con la seconda no.

      1. Probabilmente a me era andata bene, la password non era lunghissima (a memoria, 8-9 caratteri), inoltre Google non e’ l’unico motore di ricerca, inoltre/2 se oggi non lo trovi non vuol dire che la prossima settimana non ci sia.

        Il mio concetto di fondo e’ che bisogna “salare” gli hash se la sicurezza e’ importante.

        1. Confermo che googlando sono riuscito a risolvere la maggior parte delle password degli utenti del nostro blog interno (wordpress).
          Alcune (compresa la mia) non erano banalissime, ma contenevano lettere e numeri.

          1. Beh, wordpress permette nel file di configurazione di mettere delle chiavi e dei “sali” per aumentare la sicurezza di cookie e password. Il fatto che poi praticamente nessuno lo faccia è un altro paio di maniche.

            C’è addirittura un utility ufficiale per creare queste chiavi random:
            https://api.wordpress.org/secret-key/1.1/salt/
            vanno solo ricopiate nel file di configurazione.

            1. Per gli utenti nuovi credo sia automatico: vedo degli hash più complessi nel database.
              Ma la maggior parte di quelli “vecchi” si sono registrati con versioni di WP meno recenti ad hanno ancora un hash semplice. Non avendo mai cambiato la password sono rimasti così.
              Ho notato la stessa cosa in altri blog sempre WP.

        2. @Luigi: hai ragione. Articolo molto utile.

          Ho già modificato i miei software aggiungendo il “sale”. 🙂
          Ora è tutta un’altra cosa. 🙂

Spazio per un commento