Alfonso Maruccia

LinkedIn, dati in fuga

Il social network "professionale" nei guai per la pubblicazione online di milioni di password di accesso corrispondenti ad altrettanti utenti del network. Come se non bastasse, l'app LinkedIn per iOS fruga tra i dati dei contatti

Roma - È un uno-due micidiale, quello subito da LinkedIn in queste ore: prima messo sulla graticola per il comportamento irrispettoso della privacy della sua app per iOS, il social network per professionisti deve poi fare i conti con il probabile leak in rete di milioni di password appartenenti ai suoi utenti.

La questione iOS è inquietante: ricercatori di sicurezza hanno scoperto che l'app LinkedIn per iPhone e iPad ha il vizio di risucchiare tutte le informazioni personali dei contatti presenti nel calendario degli utenti, trasmettendo poi i dati (email e password incluse) verso il calendario proprio di LinkedIn.

La funzionalità è attiva solo nel caso in cui l'utente decidesse di avvantaggiarsi della sincronizzazione col calendario (opt-in), nondimeno LinkedIn è costretta a fronteggiare critiche e polemiche e infine a promettere modifiche alla sua app. D'altronde LinkedIn non è certo la sola a gestire con leggerezza i dati degli utenti (e dei contatti degli utenti), e della faccenda si sta occupando anche il Congresso USA.
Passando dalla politica alla sicurezza della sua infrastruttura telematica, infine, LinkedIn deve anche porre rimedio - se la cosa fosse mai possibile - alla distribuzione non autorizzata di oltre 6 milioni di password appartenenti ad altrettanti utenti del social network. Per Mikko Hypponen di F-Secure la raccolta di dati è autentica, e LinkedIn ha comunicato di essere impegnata a investigare sulla faccenda. Per gli utenti del network è invece consigliabile modificare la password di accesso il prima possibile.

Alfonso Maruccia
Notizie collegate
14 Commenti alla Notizia LinkedIn, dati in fuga
Ordina
  • 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 .....
    non+autenticato
  • 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...
    non+autenticato
  • 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.
    non+autenticato
  • 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.
    non+autenticato
  • 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
    non+autenticato
  • 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 cazzo 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.
    non+autenticato
  • 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.
    non+autenticato
  • - 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 fregare? 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 accesso al sistema come quell'utente!
    non+autenticato
  • - Scritto da: diffamante
    > Assolutamente falso. I salt non solo si possono
    > usare anche con le funzioni one-way, si DEVONO
    > usare anche con
    > quelle

    Ovviamente 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.
    non+autenticato
  • - 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.
    non+autenticato
  • A geni! vi è bastato leggere due righe per risolvere il problema di un'azienda da milioni euro e dozzine di ingegneri (e non) con le palle.
    Tornatevene alla vostra psp e wii.
    non+autenticato
  • - Scritto da: povera italia
    > A geni! vi è bastato leggere due righe per
    > risolvere il problema di un'azienda da milioni
    > euro e dozzine di ingegneri (e non) con le
    > palle.
    > Tornatevene alla vostra psp e wii.

    Qui nessuno cerca di risolvere nessun problema. Sono commenti liberi e in questo caso ben argomentati. Approfittane per farti una cultura, magari sottoponendo un parere ragionato e leggendo cosa gli altri hanno da dire, senza pregiudizi o atteggiamenti di superiorità.
    non+autenticato
  • - Scritto da: Filippo P.
    > - 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.

    Riflettendoci meglio, anche se le postille non riguardano strettamente le argomentazioni tecniche sopra ben esposte, sempre nell'ottica di non amplificare eccessivamente il problema, forse è meglio riportarle comunque.

    La postilla principale riguarda l'associazione tra password e utenza. Ogni password deve essere correttamente associata all'utente e pare che l'associazione tra la password e il suo utente (indirizzo email), al momento, non sembra essere stata compromessa. In un contesto con poche utenze, questo non è un fattore mitigante. In un network come Linked-In, invece, dovrebbe mitigare fortemente il problema.

    La seconda postilla riguarda il fatto che, per quanto veloci, non si può pensare di calcolare tutti gli hash "al volo". Ovviamente esistono le rainbow tables e i dizionari, tuttavia la premessa è sempre la stessa: la password scelta deve essere intrinsecamente debole.
    Questo non giustifica certo le minori cautele (dovrebbe essere chi fornisce il servizio a occuparsi della sicurezza, non chi ne usufruisce), tuttavia è innegabile che chi non usa password robuste è più esposto.

    Ribadisco: nulla da eccepire sulle questioni tecniche, l'errore grossolano era il mio (pur non essendo digiuno di sicurezza anche se non è la mia specializzazione, non ho riflettuto bene sul problema e questo è il più grande errore che si possa commettere)... solo precisazioni per inquadrare il problema nella giusta luce, senza amplificarlo eccessivamente ne' liquidarlo sbrigativamente come irrilevante.
    non+autenticato
  • bravo, è difficile trovare qualcuno che ammetta i propri errori
    non+autenticato