ACTA, quarto no dall'Europa

Contraria all'adozione del trattato anche la Commissione Sviluppo (Deve), che ha chiesto a quella per il Commercio Internazionale di bocciarne l'adozione

Roma – 19 voti a favore, un solo contrario e tre astenuti. La Commissione Sviluppo (Deve) al Parlamento d’Europa ha così bocciato l’attuale versione del famigerato Anti-Counterfeiting Trade Agreement (ACTA). Chiedendo alla Commissione Commercio Internazionale di respingere l’adozione del trattato globale anti-contraffazione .

I membri della Deve hanno così seguito lo stesso parere espresso alla fine di maggio dalle Commissioni Giuridica, Industria e Libertà Civili. È di fatto il quarto no all’accordo internazionale che vorrebbe estendere a livello globale la tutela della proprietà intellettuale e industriale.

Le preoccupazioni mostrate dalla Commissione Sviluppo sono relative alle possibili conseguenze sul libero accesso al settore distributivo dei medicinali . Contrario alla bocciatura il relatore ceco Jan Zahradil: “ACTA non creerà interferenze con l’accesso alla medicina e, in particolare, con il commercio di farmaci generici”.

Sempre secondo Zahradil, “non vi sarà alcun obbligo di eseguire controlli alle frontiere e di applicare le disposizioni relative alle sanzioni penali per presunte violazioni brevettuali nel caso di medicinali destinati a paesi che dipendono dall’importazione di tali prodotti”. La decisione della Commissione Commercio Internazionale è prevista per il prossimo 21 giugno .

Mauro Vecchio

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • CastigaTrol l scrive:
    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 .....
    • TheQ. scrive:
      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...
    • diffamante scrive:
      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.
    • Skywalker scrive:
      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.
    • Francesco scrive:
      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.
  • TheQ. scrive:
    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
  • diffamante scrive:
    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.
    • Filippo P. scrive:
      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.
      • diffamante scrive:
        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!
        • diffamante scrive:
          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.
        • Filippo P. scrive:
          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.
          • povera italia scrive:
            Re: Il problema del leak delle password...
            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.
          • Filippo P. scrive:
            Re: Il problema del leak delle password...
            - 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à.
          • diffamante scrive:
            Re: Il problema del leak delle password...
            - 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.Classico esempio di come sia inutile parlare di argomenti tecnici su PI... quando il livello è infimo come questo.
          • Filippo P. scrive:
            Re: Il problema del leak delle password...
            - 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.
          • dimmi chi sei scrive:
            Re: Il problema del leak delle password...
            bravo, è difficile trovare qualcuno che ammetta i propri errori
Chiudi i commenti