ACTA, quarto no dall'Europa

Il problema del leak delle password...
Non è soltanto quello del leak... il problema, e ben più grave, è che sono tutte salvate con sha1 SENZA NEANCHE UN SALT! Ma dico, ma scherziamo? Ma quante XXXXX di volte bisogna dire che le password nei database non vanno mai salvate con un semplice hash ma bisogna SEMPRE aggiungere un salt prima di calcolare l'hash? Sono state rubate 6.5 milioni di password, il che significa che un salt avrebbe reso il tentativo di craccarle 6.5 milioni di volte più lungo in termini di tempo! Che LinkedIn, un sito di milioni e milioni di utenti, abbia delle politiche di sicurezza così squallide è VERGOGNOSO.

Re: Il problema del leak delle password...
Che l'uso di un salt (o seed, o seme che dir si voglia) possa migliorare il livello di sicurezza è possibile, a patto che sia usato correttamente.Sostenere che il suo "non uso" implichi di contro una riduzione del tempo necessario a craccare le password pari a tante volte quant'è il numero di password disponibili, mi sembra invece grossolanamente sbagliato.Per essere più specifico, l'uso di un seme è fondamentale in caso si vada a cifrare la password su database con un sistema di crittografia "two-way" (per indenterci, DES, AES, RSA), poichè con un po' di ingegno in assenza di un seme si può ricavare l'algoritmo utilizzato per la cifratura e quindi applicare modelli cripto-analitici per ridurre il tempo necessario a decifrare la "master password" con cui poi decifrare tutte le altre. Da notare comunque che si prova a verificare gli algoritmi moderni anche in relazione a questi scenari, per cui la sicurezza non è necessariamente compromessa.Nel caso di hash "one-way" invece l'uso di un seme aiuta ma non è così importante poichè per loro stessa natura questi algoritmi non consentono di risalire con certezza al valore originario e, comunque, l'operazione deve essere ricominciata da zero con ogni nuova password.Algoritmi come SHA-1, che entro pochi anni verranno comunque sostituiti da nuovi algoritmi, anche se hanno subito attacchi che in modo matematico hanno dimostrato di poter ridurre il tempo necessario per l'individuazione di una collisione, grazie al numero di bit che li compongono (nel caso di SHA-1, 128) sono ancora ritenuti sufficientemente sicuri.Deplorevole che LinkedIn abbia "perso" 6.5mln di password, questo senz'altro... ma cerchiamo di dire le cose nel modo corretto, altrimenti si finisce per provocare ancora più danni.

Re: Il problema del leak delle password...
- Scritto da: Filippo P.> Che l'uso di un salt (o seed, o seme che dir si> voglia) possa migliorare il livello di sicurezza> è possibile, a patto che sia usato> correttamente.> > Sostenere che il suo "non uso" implichi di contro> una riduzione del tempo necessario a craccare le> password pari a tante volte quant'è il numero di> password disponibili, mi sembra invece> grossolanamente> sbagliato"Grossolanamente sbagliato"? Ah ah ah.Invece è corretto ed è proprio quella la funzione del salt, dato che non usando un salt puoi craccare tutte le password in parallelo. Con un salt, invece, devi craccarle una alla volta.Con un attacco a dizionario, ad esempio, cosa fai? Calcoli gli hash di tutte le parole che hai a disposizione nel dizionario. Una volta fatto questo, per ciascuni degli hash calcolati puoi cercare in TUTTO il database. Con un salt, invece, devi calcolare gli hash per CIASCUNO dei salt e poi puoi cercare SOLO SU UN SINGOLO RECORD CORRISPONDENTE A QUEL SALT.Calcolando l'hash sha1 di "pippo" (d012f68144ed0f121d3cc330a17eec528c2e7d59), a questo punto se non viene usato un salt puoi vedere con un semplice comando tipo "grep" (o con una semplice query nel DB) quali siano gli utenti che usano "pippo" come password, che avranno appunto d012f68144ed0f121d3cc330a17eec528c2e7d59 nel DB.Se viene usato un salt diverso per ogni utente, mi spieghi come faresti, visto che l'hash tiene conto del salt che è unico per ogni utente?Un utente che usa "pippo" come password e ha salt "ffd384" avrà un hash diverso da uno che usa "pippo" come password e ha salt "4585uc": puoi solamente calcolare gli hash delle parole del dizionario PER OGNI SINGOLO SALT, e quindi tentare di craccare ogni singolo record uno alla volta.Una bella differenza.> > Per essere più specifico, l'uso di un seme è> fondamentale in caso si vada a cifrare la> password su database con un sistema di> crittografia "two-way" (per indenterci, DES, AES,> RSA), poichè con un po' di ingegno in assenza di> un seme si può ricavare l'algoritmo utilizzato> per la cifratura e quindi applicare modelli> cripto-analitici per ridurre il tempo necessario> a decifrare la "master password" con cui poi> decifrare tutte le altre. Da notare comunque che> si prova a verificare gli algoritmi moderni anche> in relazione a questi scenari, per cui la> sicurezza non è necessariamente> compromessa.Assolutamente falso. I salt non solo si possono usare anche con le funzioni one-way, si DEVONO usare anche con quelle.> Nel caso di hash "one-way" invece l'uso di un> seme aiuta ma non è così importante poichè per> loro stessa natura questi algoritmi non> consentono di risalire con certezza al valore> originario e, comunque, l'operazione deve essere> ricominciata da zero con ogni nuova> password.COSA? Ovviamente non consentono di risalire al valore originario ma con una buona probabilità con un attacco a dizionario o con un password cracker comune risali al valore originario, ma ANCHE SE NON FOSSE, che diamine te ne potrebbe XXXXXXX? A te interessa soltanto trovare un valore che produce lo stesso hash, quindi che te le frega dell'eventuale remota possibilità che la password non fosse quella se l'hash calcolato è lo stesso? Se l'hash calcolato è lo stesso accedi comunque!> Algoritmi come SHA-1, che entro pochi anni> verranno comunque sostituiti da nuovi algoritmi,> anche se hanno subito attacchi che in modo> matematico hanno dimostrato di poter ridurre il> tempo necessario per l'individuazione di una> collisione, grazie al numero di bit che li> compongono (nel caso di SHA-1, 128) sono ancora> ritenuti sufficientemente> sicuri.Sicuri? Gli algoritmi di hash non sono reversibili, il problema non è che vengano o meno "craccate" le password rendendoli reversibili (che non è possibile), il problema è che essendo velocissimi ci si mette davvero poco a calcolare gli hash di milioni di parole e combinazioni di parole e numeri (per esempio "p1pp0" invece di "pippo"): una volta che hai trovato una corrispondenza tra un hash calcolato e un record del DB, hai acXXXXX al sistema come quell'utente!

Re: Il problema del leak delle password...
- Scritto da: diffamante> Assolutamente falso. I salt non solo si possono> usare anche con le funzioni one-way, si DEVONO> usare anche con> quelleOvviamente se vengono usati per un uso come quello di salvare le password in un DB multiutente, non quello di "verifica" dell'hash di un determinato file, nel qual caso ovviamente l'uso del salt non ha senso.

Re: Il problema del leak delle password...
- Scritto da: diffamante> - Scritto da: Filippo P.> > Che l'uso di un salt (o seed, o seme che dir si> > voglia) possa migliorare il livello di sicurezza> > è possibile, a patto che sia usato> > correttamente.> > > > Sostenere che il suo "non uso" implichi di> contro> > una riduzione del tempo necessario a craccare le> > password pari a tante volte quant'è il numero di> > password disponibili, mi sembra invece> > grossolanamente> > sbagliato> > "Grossolanamente sbagliato"? Ah ah ah.Devo ammettere che ho inquadrato il problema dalla prospettiva sbagliata. Un salt influisce notevolmente sulla sicurezza e sotto hai ben esposto le argomentazioni. Ho alcune postille, ma sarebbero poco rilevanti. Hai ragione.L'errore grossolano era il mio.

curriculum vitae
linkein, se ha nel database i curriculum vi sono non solo le password, ma anche i dati personali quali numeri di telefono o luogo di residenza...veramente brutta questa notizia

Re: curriculum vitae
hai proprio ragione, il mondo trabocca di stupidi e tu ne sei la prova

Beh....
Se uno è così tonto da mettere dati PERSONALI su uno di questi "social network", si merita AMPIAMENTE che gli siano rubati.Per non parlare delle app di questo genere sul cellulare.Il mondo è pieno di stupidi, e continuano a riprodursi.Non siamo messi bene .....

Re: Beh....
prova ad essere laureato disoccupato con la prospettiva di lavorare in un call center a 500 euro al mese come precario.Poi vedrai che scrivi dati veri nel curriculum vitae e li pubblichi in appositi servizi stile agenzie interinali...

Re: Beh....
- Scritto da: CastigaTrol l> Se uno è così tonto da mettere dati PERSONALI su> uno di questi "social network", si merita> AMPIAMENTE che gli siano> rubati.> Per non parlare delle app di questo genere sul> cellulare.> > Il mondo è pieno di stupidi, e continuano a> riprodursi.> Non siamo messi bene .....Tu sicuramente non sei messo bene, che non sai neanche bene cosa sia LinkedIn.

Re: Beh....
Su LinkedIn quali dati personali vuoi mettere? La stragrande maggioranza ci mette dati professionali: conoscenze professionali, percorsi formativi, esperienze lavorative, incarichi professionali.Anche l'indirizzo email di solito non è quello con cui ti scrivi con gli amici e se ci metti un cellulare, non è certo quello personale.Tu quando vai ad Convegno agli altri presenti non dai il tuo biglietto da visita? E sul biglietto da visita di solito io non scrivo l'indirizzo ed il numero di telefono di casa, né tantomento cosa faccio il sabato sera.Quindi non capisco il tuo sfogo.Il problema non è quello che sta in LinkedIn per la quasi totalità già pubblico. Il problema sta che qualcuno potrebbe alterare il mio profilo o millantare credito da parte mia senza che l'abbia mai conosciuto.Che è un altro problema, diverso dalla Privacy.

Re: Beh....
Guarda che si parlava di Linkedin, non fessbook. Non so se ti è chiara la differenza.Certo che se poi uno si diverte a fornire a qualsiasi servizio la possibilità di correlare il proprio nominativo cedendo indirizzi e-mail ed altro...bhé... cavolacci suoi.