Newsgroup: it.comp.www.php
Titolo: Password hash: bcrypt VS salt (md5, sha, etc..)

In una discussione recente è saltato fuori questo link: 
http://codahale.com/how-to-safely-store-a-password/
 
 
E mi sono sorti dei dubbi: ok, bcrypt si può scegliere quanto _lento_ farlo diventare per scoraggiare i brute-force, ma da quel che ho capito è anche lui one-way, pertanto il discorso regge solo nel momento in cui qualcuno accede al server e si scarica la tabella delle password hashate, altrimenti, sarà il nostro applicativo che:
 
1. col cavolo che permette 700,000,000 richieste al secondo, manco i serve di google
2. dopo n tentativi falliti banna l'ip per X secondi e pace e amen al brute force.
 
O mi stò perdendo qualcosa?
 
Inoltre, anche recuperando le tabelle con gli hash, se l'hash è composto da 2 o più salt, è praticamente impossibile andare di brute force se non si conosce ordine, posizione e stringa dei salt, giusto?

 giusto?
 
Per quello che ho capito io, non � proprio cos�. Immagina che ci sia un 
salt unico (diviso e mescolato come vuoi) per tutti i record del 
database. Se qualche utente ha impostato password di un solo carattere, 
� sufficiente arrivare a scoprire quelle per capire come � strutturato 
il salt e passare a decrittare le altre password.
Ecco perch�, pi� che il mescolamento del salt che hai descritto, conta 
la sua definizione a livello di record anzich� di intera tabella: � cio� 
opportuno impostare una regola che crei un valore del salt diverso per 
ogni record. In quest'ultimo caso la decrittazione di una password non � 
utile per la decrittazione delle altre password, e i tempi per mettere 
in chiaro tutte diventa proporzionale al numero dei record nel database.
I casi di croncaca recente portano a concludere che tale meccanismo non 
� stato granch� implementato...

 è stato granché implementato...
 
Capito. 
Io finora gestivo 3-4 salt che venivano mescolati con una struttura definita per ogni installazione, ad esempio:
 
 
 
$hash = hash($algo1, sprintf("%s%s%s", $salt1, $password, $salt1));
$hash = hash($algo2, sprintf("%s%s", $hash, $salt2));
$hash = hash($algo4, sprintf("%s%s", $salt3, $hash));
 
L'utilizzo di hash diversi per ogni password presuppone si usare un altro valore che sia comunque legato all'utente (oppure generato a random ma poi salvato nell'utente), che sò, l'indirizzo mail, data di registrazione, etc...
 
Così hai si i salt diversi, ma se il cracker riesce a scaricarsi il db ci sono buone probabilità che possa arrivare anche ai sorgenti dell'applicazione e quindi vedere l'ordinamento e gli hash... nel caso di php poi, se fossi io il cracker mi installerei l'applicativo in locale, toglierei tutti i controlli temporizzati sul login e farei li il brute force..
 
Insomma, una volta che il cracker si scarica i database effettivamente l'unica _salvezza_ potrebbe essere bcrypt, anche se a mio avviso a quel punto si ha già un piede nella fossa e non rimane che avvisare tutti gli utenti di cambiare le password, aggiornare gli hash, etc..

 Insomma, una volta che il cracker si scarica i database effettivamente
 > l'unica _salvezza_ potrebbe essere bcrypt, anche se a mio avviso a quel
 > punto si ha gi� un piede nella fossa e non rimane che avvisare tutti
 > gli utenti di cambiare le password, aggiornare gli hash, etc..
 
Comunque la si metta l'uso di ID/Password � e rimarr� sempre un metodo 
di autenticazione insicuro per definizione.
 
Eliminare le password e passare ai certificati digitali (possibilmente 
su supporto hardware come smart card) o software per i dispositivi 
mobili � ad oggi l'unica soluzione in grado di garantire totale 
sicurezza se correttamente integrata con i dovuti controlli via ocsp.
 
Questo elimina del tutto la possibilit� di rubare le credenziali anche 
attraverso key logger et similia lato client.
 
Ovviamente in caso di furto di un dispositivo mobile contenente 
certificati pkcs#12 l'utente deve immediatamente bloccare il certificato 
presso la propria CA.

 presso la propria CA.
 
Mentre nel frattempo il cracker gli ha fottuto tutte le credenziali a tutti i siti e, problmea sarebbe ancora maggiore, nel momento in cui il certificato e' univoco per ogni persona, quindi tu sei il tuo certificato, quindi te lo frego ed ecco che ti ho fregato la tua vera identita' non solo a su facebook o linkedin o youporn.
 
Ogni cosa ha i suoi vantaggi e svantaggi e va sempre vista in funzione dello scopo o si rischia sempre di sparare con un bazooka a un passerotto.
 
Per fare un esempio banale, quanti credi userebbero facebook o twitter o wordpress o qualsiasi cosa fatta e pensata per gli utenti e non per gli "addetti ai lavori" se avessero dovuto acquistare un token e tutte le volte ficcarlo nel pc?
La gente non vuole nemmeno inserire le password e resta loggata per sempre in tutti i siti, figurati se impazzisce a ficcare il coso nel pc, per non pensare a quanti usano "internet" dagli internet point, tu ficcheresti la tua smart card in un aggeggio di un internet cafe'? Io no.
 
Anyway, per dispositivo mobile intendi telefono o tablet?
Chi e' il pazzo che tiene un certificato privato (o una chiave privata) su un telefono che te lo fregano col bluetooth o con 2 sms??? Tanto vale tatuarsi le password per non scordarle.
 
Le chiavi vanno sempre tenute in una smart card e non si deve mai perdere di vista.
 
J.

 perdere di vista.
 
Possibilmente, nessuno vieta di accettare *esclusivamente* quelle emesse 
dalle CA accreditate, così come nessuno vieta di farsi una propria CA e 
distribuire i propri .p12 per dispositivi mobili fatte le dovute 
valutazioni dei rischi.
 
 

 valutazioni dei rischi.
 
E qui son daccordo
 
Ma il succo e' che per il 90%, se non 97% del mercato, username e password sono il metodo migliore, quindi bcrypt o salt o quello che si vuole siano importati e sufficienti.
 
 
Un ultima domanda, perche' spingi sempre sulla tessera sanitaria o cose di questo tipo, nel senso perche' vuoi individuare la persona e non l'utente?
In fondo sono veramente poche le situazioni dove devi essere sicuro della persona, giusto bancari ed eventualmetne interazioni con la PA.
 
J.

 PA.
 
Come dimostrato sopa, la tua visione della situazione reale � limitata,
oggi sono moltissimi i casi in cui � necessario riconoscere la persona
per offrire un servizio decente ed eliminare eventualmente (in modo
definitivo) le mele marce che fanno guastare l'intero cesto.
 
D'altra parte un dominio � propriet� di qualcuno e se permetti io voglio
sapere chi entra e chi esce da casa mia dato che non � un luogo pubblico.
 
E chi non rispetta le regole della casa pu� accomodarsi all'uscita.
 
Nel primo caso il furbetto di turno registra un altro account e rientra
dalla finestra riprendendo allegramente le proprie attivit� nel secondo
una volta bannato adios amigos.
 
 
 
 
 
 

 luogo pubblico.
 
LIberissimo, ma chi pubblica un servizio in genere vuole che lo
si usi. Immagina un e-commerce che ti richiede il certificato per
fare login quanti affari pu� fare.
E pure se voglio mettermi a commentare in un blog di politica
non � detto che ti voglia dire con precisione chi sono.
 
Per limitare gli abusi esistono altri sistemi di pi� semplice
implementazione e che non limitano gli accessi anche ai benintenzionati.
-- 
ValeRyo 
 
 

 implementazione e che non limitano gli accessi anche ai benintenzionati.
 
Quindi il tuo problema ï¿œ la difficile implementazione di un sistema 
basato sui certificati, parliamone e vediamo come renderla semplice.
 

 basato sui certificati, parliamone e vediamo come renderla semplice.
 
Capire come rendere semplice l'implementazione mi interessa, anche se sto implementando una soluzione diversa penso che implementata una smart card funzioni con tutta, o sbaglio?
 
Il vero problema pero' e' che questa implementaazione e' un implementazione che in tantissimi casi porterebbe ad un calo degli utenti, quindi non e' interessante per moltissime applicazioni.
 
J.

 una volta bannato adios amigos.
 
Certo il problema di internet sono i trolloni, a morte i troll! 
Lol.. ma non ho resistito!
 
J.
 

 appositi lettori USB HID vedi 
http://www.pec.it/ArubaKey.aspx
 
 
Non no capito una cosa, come e dove viene generato il certificato privato?
 
A me sembra la versione closesource (e + costosa) di questa: 
http://shop.crypto-stick.com/en/10-gpf-cryptostick-12.html
 
 
 
J.
 

 A me sembra la versione closesource (e + costosa) di questa: 
http://shop.crypto-stick.com/en/10-gpf-cryptostick-12.html
 
 
Centra nulla, la prima �
costo dell'hardware
+ certificato di firma digitale
+ certificato di autenticazione
legalmente validi ovvero emessi da una CA accreditata da uno stato 
europeo (validit� dei certificati 3 anni rinnovabili)
 
L'altro � il solo costo dell'hardware senza certificati
 
 

 Mi puoi fare qualche esempio?
 
Perch� pensi che pochissime PA mettono a disposizione forum o ML, perch�
chi l'ha fatto � rimasto scottato proprio dall'anonimato reale o
presunto che sia


 L'altro è il solo costo dell'hardware senza certificati
 
Ok, spiegata la differenza di prezzo, quindi sono la stessa cosa, solo che nel secondo caso le chiavi se le genera l'utente, giusto?
 
J.

 presunto che sia
 
???
Intendevo qualche esempio di servizio in cui sia necessario identificare la persona e non l'utente che non siano bancari e PA come ho scritto pure io.
 
 
J.

 procedura di recovery ti svela l'arcano.
 
Questa � una condizione sufficiente ma non necessaria.

 basato sui certificati, parliamone e vediamo come renderla semplice.
 
Non è un mio problema, vivo benissimo con username e password.
Ti facevo notare che un sistema di login basato sui certificati, *qui e 
oggi*,
sarebbe una barriera alla diffusione del sito che lo implementi.
 
-- 
ValeRyo