[HackMe] Nuovo metodo più sicuro per storage di password

[zacca94]

Ciao a tutti,
Mi infilo anche io in questa discussione perché sono un ricercatore nel campo della crittografia e sono quindi interessato al tema. Premetto che la mia specialità non sono le hash functions, ma ho letto e conosco un po' di cose sul tema.

Dopo aver letto i vari post, mi trovo d'accordo con Scara95: sembra che la possibilità di "sparare a caso" in una tabella più grande non possa che aumentare il rischio di collisioni. La questione della struttura salt+password non sembra rilevante: l'unica cosa che serve è una collisione nella funzione di hash. Ora, se hai un solo bersaglio allora hai una certa probabilità di successo. Ma in questo caso sembra che i bersagli possibili siano potenzialmente molti di più. Quindi è per forza più semplice trovare una collisione. Tra l'altro, anche la questione della lunghezza delle stringhe non sembra importante: qualunque input, di qualunque lunghezza, viene mappato su un output di lunghezza fissa. Quindi uno può semplicemente fare hash di input completamente casuali e di qualunque lunghezza. Ogni collisione porta ad un accesso non autorizzato.

Ovviamente, tutto questo se ho capito bene il problema

Grazie della risposta, sono contento che si interessi qualcuno che è legato all'ambito.

Il punto della questione che mi chiedevo è:

Quindi uno può semplicemente fare hash di input completamente casuali e di qualunque lunghezza.

Sempre a patto che POSSA fare input di qualsiasi lunghezza.

Ipotizziamo che io importo password di 4 caratteri fissi (nella realtà sarebbe piuttosto stupido) e un salt di 4 caratteri.
L'attaccante nel login non potrebbe puttare in input quello che vuole, mentre sarei certo che i vari hash512 sarebbero tutti univoci (ora non sono capace di fare i calcoli ma ipotizzo che per 8byte ci sia univocità), no?

[minomic]

Grazie della risposta, sono contento che si interessi qualcuno che è legato all'ambito.

Il punto della questione che mi chiedevo è:

Sempre a patto che POSSA fare input di qualsiasi lunghezza.

Ipotizziamo che io importo password di 4 caratteri fissi (nella realtà sarebbe piuttosto stupido) e un salt di 4 caratteri.
L'attaccante nel login non potrebbe puttare in input quello che vuole, mentre sarei certo che i vari hash512 sarebbero tutti univoci (ora non sono capace di fare i calcoli ma ipotizzo che per 8byte ci sia univocità), no?

Secondo me qui c'è qualcosa che non va... La lunghezza dell'input non ha niente a che vedere con l'output. L'output è di lunghezza fissa, qualunque sia la dimensione dell'input.

Forse quello che tu intendi è che se prendi pochi possibili input, allora gli output sono tutti diversi, e questo è vero con alta probabilità. Ma questo non ti salva.

Supponi che la tua password sia "abcd" e il salt "1234". Se fai sha256 di "abcd1234" ottieni
e9cee71ab932fde863338d08be4de9dfe39ea049bdafb342ce 659ec5450b69ae
Ma ci sono molte altre stringhe che hanno lo stesso hash, e un avversario non è limitato a una particolare struttura di input. Può mettere quello che vuole, e se trova una collisione, entra. Con il tuo sistema gli stai dando più possibili bersagli (hash) da colpire.

[zacca94]

Va anche detta un'altra cosa.
Da cos'è che dovrebbe proteggere questa cosa?

In linea massima protegge solo dal non "rivelare" la vera password all'attaccante, però se ha equivalenza a hashare ricorsivamente 1000 volte (come nel tuo esempio), allora è inutile e lascio perdere...

[zacca94]

Ma ci sono molte altre stringhe che hanno lo stesso hash, e un avversario non è limitato a una particolare struttura di input. Può mettere quello che vuole, e se trova una collisione, entra. Con il tuo sistema gli stai dando più possibili bersagli (hash) da colpire.

Si hai ragione, io mi riferivo tipo "login", se ha accesso direttamente al file /etc/shadow o al db il mio discorso non ha senso...

Mi sa che ho solo buttato del tempo :/

[minomic]

Mi sa che ho solo buttato del tempo :/

Parlo per esperienza personale quando dico che nella ricerca si fallisce spesso, prima di arrivare a qualcosa. Ma raramente si tratta davvero di tempo perso. Hai imparato qualcosa, anche magari di aver sbagliato? Allora non è stato perso ;-)

[MItaly]

In linea massima protegge solo dal non "rivelare" la vera password all'attaccante, però se ha equivalenza a hashare ricorsivamente 1000 volte (come nel tuo esempio), allora è inutile e lascio perdere...

Il punto è che non è che non la rivela, la rivela ma nel mucchio con altra roba, il che rende più lento verificare di aver fatto un guess corretto (ma viceversa, appunto per il discorso delle collisioni di cui sopra, ti consente magari di beccarne un'altra che non era quella a cui stavi puntando); questo per come la vedo io di fatto si traduce semplicemente in un rallentamento di ogni tentativo, che è simile come concetto all'hashing ricorsivo (che peraltro in una sua variante è il sistema già usato su Linux e BSD per memorizzare le password).

La differenza principale è il tipo di rallentamento - la differenza tra avere uno sfacelo di hash tra cui cercare e il dover ri-hashare uno sfacelo di volte è che il tuo sistema richiede più RAM, e quindi è più costoso/complicato da implementare in maniera ultra-efficiente in hardware custom. Viceversa, attualmente esistono diversi approcci pensati appositamente per rendere il problema complesso per ASIC e GPU senza però richiedere di memorizzare "per davvero" un mucchio di hash-spazzatura.

In ogni caso, se vuoi giocare a integrare questo genere di cose nel sistema operativo su Linux puoi usare PAM, senza dover mettere mano al kernel.

[zacca94]

Parlo per esperienza personale quando dico che nella ricerca si fallisce spesso, prima di arrivare a qualcosa. Ma raramente si tratta davvero di tempo perso. Hai imparato qualcosa, anche magari di aver sbagliato? Allora non è stato perso ;-)

Ho ancora una domanda per curiosità (quella proposta precedentemente):
Se io imponessi input di lunghezza fissa (password+salt = [sempre stesso numero di caratteri]) potrei prevenire la (im)probabilità matematica di collisione, se si, quale è questa lunghezza? (nelle sha512)

[minomic]

Ho ancora una domanda per curiosità (quella proposta precedentemente):
Se io imponessi input di lunghezza fissa (password+salt = [sempre stesso numero di caratteri]) potrei prevenire la (im)probabilità matematica di collisione, se si, quale è questa lunghezza? (nelle sha512)

Onestamente, non credo di saper rispondere. Ma non so nemmeno se una risposta esista oppure no. Se non limiti la capacità dell'avversario di mettere in input quello che vuole, allora non vedo come si possano prevenire le collisioni. Se invece limiti la capacità dell'avversario e lo costringi a mettere in input qualcosa di lunghezza determinata, allora non saprei... L'output di una buona funzione di hash è ben distribuito, ma questo non significa che l'hash di 1234 non sia lo stesso di 5678. E' solo molto improbabile, ma non impossibile. Quindi, in teoria, non credo che tu possa prevenire collisioni. Ma di questo non sono certo, non essendo proprio il mio campo specifico.

[zacca94]

Onestamente, non credo di saper rispondere. Ma non so nemmeno se una risposta esista oppure no. Se non limiti la capacità dell'avversario di mettere in input quello che vuole, allora non vedo come si possano prevenire le collisioni. Se invece limiti la capacità dell'avversario e lo costringi a mettere in input qualcosa di lunghezza determinata, allora non saprei... L'output di una buona funzione di hash è ben distribuito, ma questo non significa che l'hash di 1234 non sia lo stesso di 5678. E' solo molto improbabile, ma non impossibile. Quindi, in teoria, non credo che tu possa prevenire collisioni. Ma di questo non sono certo, non essendo proprio il mio campo specifico.

Ultima domanda e concludo (perdona la mia ignoranza), esistono funzioni di hashing univoche per lunghezze di stringhe determinate?

Vi ringrazio, minomic, Scara95 e MItaly ancora per il tempo speso.

[minomic]

esistono funzioni di hashing univoche per lunghezze di stringhe determinate?

Personalmente, non ne ho mai sentito parlare. In ogni caso mi sembrerebbe una definizione piuttosto strana di "hash function"...