Mozilla offentliggør brugerdata ved en fejl

Altid trist at sådan noget sker, men stor ros for at de undersøgte problemet, og konkluderede at ingen udover interne medarbejdere og forskeren fik adgang til filen.

Derudover heldigt at det kun var inaktive kontis.

#1, og dertil slettede de alle passwords til de inaktive konti. Knap så godt er det, at Mozilla blev informeret d. 17. december, og først skrev til communitiet i går.

Alrekr (2) skrev:

#1, og dertil slettede de alle passwords til de inaktive konti. Knap så godt er det, at Mozilla blev informeret d. 17. december, og først skrev til communitiet i går.

Kunne være de lige skulle have tid til at undersøge og måske holde lidt jul også? :P

Alrekr (2) skrev:

#1, og dertil slettede de alle passwords til de inaktive konti. Knap så godt er det, at Mozilla blev informeret d. 17. december, og først skrev til communitiet i går.

Hvornår communitiet blev informeret er sådan set ligemeget, så længe filen blev taget ned med det samme.

Hvorfor fokuseres der så meget på hvilken hash der er brugt? Godt nok er der fundet kollisioner i MD5, og det er en god idé at bruge en stærkere hash. Men mig bekendt er det stadigvæk ikke spor realistisk at brute force en MD5 hash.

Uanset hvor stærkt dit password er, så vil ethvert andet password der resulterer i samme hash kunne bruges i stedet. Så med i gennemsnit 2^127 MD5 operationer kan man finde en brugers password. Det er ikke realistisk at gennemføre, så i stedet er man nødt til at gætte det rigtige password og håbe på at brugeren har valgt et af de 2^40 mest brugte passwords.

Hvis brugeren har valgt et svagt password, så kan det brydes ligegyldigt om der er brugt MD5 eller SHA512.

Så brugere hvis password er hashet med MD5 er ikke væsentligt ringere stillet end dem hvis password er hashet med SHA512.

Burde de ikke i stedet have givet brugere med et MD5 hashet password et par måneder til at skifte password?

#kasperd

Det eneste ulempe jeg umiddelbart kan komme i tanke om er at rainbow tables er væsentlig mere udbredt til MD5 fremfor SHA512.

kasperd (5) skrev:

Hvorfor fokuseres der så meget på hvilken hash der er brugt?

Fordi det er meget væsentligt for hvor nemt det er at cracke en hash.

kasperd (5) skrev:

Godt nok er der fundet kollisioner i MD5, og det er en god idé at bruge en stærkere hash.

Det er værre end det. Man kan finde kollisioner i MD5 på få sekunder på ganske almindelig hardware... MD5 bør derfor ikke længere bruges til at hashe passwords med.

kasperd (5) skrev:

Men mig bekendt er det stadigvæk ikke spor realistisk at brute force en MD5 hash.

Nej, men det betyder ikke så meget så længe man vha. kryptoanalyse kan cracke hashes på kort tid.

kasperd (5) skrev:

Hvis brugeren har valgt et svagt password, så kan det brydes ligegyldigt om der er brugt MD5 eller SHA512.

Ja, såfremt passwordet er under en vis længde og ikke indeholder specialtegn - så er det nemt at finde dictionaries og evt. rainbow tables. Hvis de pågældende hashes er saltede, så besværliggøres det hele dog en hel del, da de samme dictionaries/rainbow tables så ikke kan bruges til alle hashes.

kasperd (5) skrev:

Så brugere hvis password er hashet med MD5 er ikke væsentligt ringere stillet end dem hvis password er hashet med SHA512.

Det er de jo lige netop. Men selv SHA-2 er ved at være en aldrende standard - heldigvis er SHA-3 sat til at blive publiseret i 2012, så vi skal ikke vente så længe endnu på en efterfølger.

kasperd (5) skrev:

Burde de ikke i stedet have givet brugere med et MD5 hashet password et par måneder til at skifte password?

Det ville være uansvarligt - mange ville sikkert ikke gøre det eller gøre det for sent. Men nu lyder det til at de pågældende konti er inaktive - i så fald ville jeg nok være mere bekymret for om folk har brugt det samme password (sammen med e-mail-adressen der også blev lækket sammen med for- og efternavn) til andre ting.

Hamlet (7) skrev:

Det er værre end det. Man kan finde kollisioner i MD5 på få sekunder på ganske almindelig hardware... MD5 bør derfor ikke længere bruges til at hashe passwords med.

Hmm.

Der er forskellige former for brud på krypterings algoritmer bl.a.:
* collision
* first pre-image

Det er collision brud der kan laves på få sekunder for MD5.

Det er first pre-image der skal brydes for at udnytte password.

Så man kan ikke bryde de hashede password på få sekunder.

Hvilket kasperd uden tvivl ved.

Hamlet (7) skrev:

Hvis de pågældende hashes er saltede, så besværliggøres det hele dog en hel del, da de samme dictionaries/rainbow tables så ikke kan bruges til alle hashes.

Besværliggøres er vist en underdrivelse. Man er tilbage til en helt normal brute force.

kasperd (5) skrev:

Hvorfor fokuseres der så meget på hvilken hash der er brugt? Godt nok er der fundet kollisioner i MD5, og det er en god idé at bruge en stærkere hash. Men mig bekendt er det stadigvæk ikke spor realistisk at brute force en MD5 hash.

kasperd (5) skrev:

Uanset hvor stærkt dit password er, så vil ethvert andet password der resulterer i samme hash kunne bruges i stedet. Så med i gennemsnit 2^127 MD5 operationer kan man finde en brugers password. Det er ikke realistisk at gennemføre, så i stedet er man nødt til at gætte det rigtige password og håbe på at brugeren har valgt et af de 2^40 mest brugte passwords.

MD5 collision attack er nede på 2^21 eller 2^24 kompleksitet og derfor et problem i praksis.

MD5 first pre-image attack er kun nede på 2^123 kompleksitet, hvilket ikke er et problem i praksis.

Så jeg kan godt følge din skepsis lidt.

Men givet at:
1) ifølge artiklen er der ikke brugt salt før 2009 (hvor man skiftede fra MD5 til SHA512), hvilket gør diverse tables til et reelt problem
2) at MD5 har problemer har været kendt i snart mange år
3) bedre alternativer har været kendt i en del år
4) disse bedre alternativer koster ikke nævneværdigt flere ressourcer
så synes jeg godt at man kan sige, at Mozilla ikke har gjordt deres bedste.

#10

Strengt matematisk har en given hash algoritme en given kompleksitet ved de kendte angreb. End of story.

Men ved en sikkerhedsvurdering kan man godt "gætte" på udviklingen i fremtidige angreb.

Jeg mener at det er almindeligt at antage at:
1) findes der et brud som som reducerer kompleksiteten, så er sandsynligheden større for at der indenfor et par år findes et nyt brud som yderligere reducerer kompleksiteten
2) findes der collision bruf så er sandsynligheden større for at der indenfor et par år findes pre-image brud

Matematisk set er det noget humbug.

Men empirisk er der et vist belæg for det.

Og der er en godt forklaring på kausaliteten:
- ideer i fundne brud kan genbruges i nye brud
- brud skaber interesse og dermed flere som arbejder på problemet

På det grundlag vil jeg mene at det mest sikre et at totalt bandlyse brugen af MD5.

Hamlet (7) skrev:

Det er værre end det. Man kan finde kollisioner i MD5 på få sekunder på ganske almindelig hardware... MD5 bør derfor ikke længere bruges til at hashe passwords med.

Kollisioner er underordnede når MD5 bruges til passwords. Kun preimage attacks har betydning, og de kan på nuværende tidspunkt ikke udføres nær så hurtigt.

arne_v (10) skrev:

MD5 collision attack er nede på 2^21 eller 2^24 kompleksitet og derfor et problem i praksis.

Er man virkelig kommet så langt ned? Ved du tilfældigvis hvor man finder en artikel om det?

ifølge artiklen er der ikke brugt salt før 2009 (hvor man skiftede fra MD5 til SHA512), hvilket gør diverse tables til et reelt problem

Det lyder meget mærkeligt. Hvad er det for et system, som de har anvendt? crypt funktionen på unix systemer understøtter DES, MD5, SHA1 og SHA2 til passwords, men til alle sammen er der anvendt salt.

kasperd (12) skrev:

Er man virkelig kommet så langt ned? Ved du tilfældigvis hvor man finder en artikel om det?

http://www.win.tue.nl/hashclash/On%20Collisions%20...
http://eprint.iacr.org/2009/223.pdf

kasperd (12) skrev:

Det lyder meget mærkeligt. Hvad er det for et system, som de har anvendt? crypt funktionen på unix systemer understøtter DES, MD5, SHA1 og SHA2 til passwords, men til alle sammen er der anvendt salt.

Funktionaliteten ligger vel i den web app som håndterer folks registrering.

Så der er en eller anden web udvikler som har bixet en ikke for god løsning.

Det må være set en miilion gange før!