Evernote hacket: 50 millioner brugere skal skifte kodeord

"skyen" er helt sikker...

Ja - undtagen hvis der er solskin og skyfrit.

Koderne er hashed, ikke krypteret. Havde de været krypteret, kunne hackerne bare decryptere dem. Man kan heller ikke kryptere noget med en hash funktion, da en hash funktion er en en-vejs funktion.

Det er rigtigt at Evernote brugte salts, men det betyder ikke at koderne er "sikkert opbevaret". Evernote skriver i en kommentar på deres blok, at koderne er hashet med MD5, men de skriver intet om PBKDF2 eller at koderne har været igennem flere gange MD5-iterationer, så man kunne gætte på at koderne er gemt i databasen som: hash = md5(kode+salt) hvilket bestemt ikke er sikker opbevaring!

Hej

http://epn.dk/teknologi2/computer/article5230938.ece

Det sjove er at i 80'erne, når man ikke rigtig vidste hvor ens data smuttede hen, så tegnede man en sky.... Meget betrykkende :)... Det er titanic om igen

Ret mig hvis jeg tager fejl, men det er md5 problem ikke at det er nemt at finde en kollision? Så i og med at de har invalideret alle kodeord, så brænder det ikke mere? En langt mindre læk end den fra linked in.

Jeg har forsøgt at finde en kilde på dit udsagn om MD5. Det eneste jeg kan finde er andre (bl.a. Krebs) som skriver at Evernote ikke har fortalt om hvilken hash-funktion de har brugt.

Selvom der var anvendt md5crypt, så er den for længst uddateret.

... præcis lige så farlig som enhver anden service der kan tilgås remote.

Att. John Vedsegaard samt Hans Andersen: Hvad er din definition af "skyen"? Er det pr. definition usikkert — og hvorfor? Vi kan evt. lave en hyggelig "capture the credit card": Jeg placerer mit Visa kortnummer på en kørende EC2-maskine så jeg selv kan hive det ud igen. I får IP-adressen. Så er det bare at give den gas med hævninger på mit kort — hvis det lykkedes at få fat i kortnummeret. Giv lyd, hvis I vil lege med.

Hvis de har brugt HMAC-MD5 til at salte (f.eks. med PBKDF2), så er det ikke så galt igen:

HMACs are substantially less affected by collisions than their underlying hashing algorithms alone. Therefore, HMAC-MD5 does not suffer from the same weaknesses that have been found in MD5.

– Wikipedia om HMAC

Kan se at det var en lidt gammel blogpost jeg fandt frem til (2011), men jeg tvivler desværre meget på at de har ændret deres måde at gemme passwords på: http://blog.evernote.com/tech/2011/05/17/architectural-digest/

Morten Wegelbye Nissen: MD5 skal ikke bruges til digitale certifikater, da man 'nemt' kan finde kollisioner (og det er kun (MD5)hashet som er signeret). Men når vi gemmer passwords, er vi ligeglade med dette. Hvad vi er interesseret i, er at finde en langsom algoritme. MD5 er beregnet til at hashe mange hundrede megabyte pr sekund, så en enkelt gang MD5(DATA) kan ikke bruges. Hvis man vil bruge MD5, så lav et stort loop: FOR(i=0; i<100.000; i++){ hash = MD5(hash+password+salt); } Havde Evernote brugt et loop med 100k iterationer, så ville det kræve 5,000,000,000,000 MD5 hash operationer for at tjekke ét password mod databasen. Altså vil man teste hvem der bruger koden "12345678", kræver det 5 billioner MD5 hash operationer, og vil man se hvem der bruger koden "superman" kræver det endnu engang 5 billioner MD5 hashes, osv..

Bedst er at bruge pbkdf2/bcrypt eller en anden algoritme beregnet til at håndtere passwords. Dog er det stadig meget vigtigt at sige, at SHA1/2/3 eller HMAC-MD5 ikke løser problemet. Fx LinkedIn som brugte SHA1 og ingen salts var meget værre end Evernote hvad angår sværhedsgraden af at bryde deres hashes. MD5 + salts = meget bedre løsning end SHA1 uden salts.

("problemet" ved sikker password hashing er at det kræver mere serverside kraft, end fx en enkelt gang MD5(data), så husk også at begrænse hvor mange passwords man kan prøve (pr tid), så man ikke kan DoS'e serveren ved at sende en masse lange passwords hele tiden).

Md5+salt er vel sikkery nok. De skal blot invalidere de gamle koder med et nyt salt?

Matasano har nogle gode diskussioner om password sikkerhed, f.eks. her som en start: http://krebsonsecurity.com/2012/06/how-companies-can-beef-up-password-se...

Bare rolig "skyen" er helt sikker...

Re: Bare rolig Ja - undtagen hvis der er solskin og skyfrit.

Det sjove er at i 80'erne, når man ikke rigtig vidste hvor ens data smuttede hen, så tegnede man en sky.... Meget betrykkende :)... Det er titanic om igen

Det her er en sky Cloud computing er hardware og software - en løsning bliver ikke sikker eller usikker bare fordi man kalder det cloud.

Hvis de har brugt HMAC-MD5 til at salte (f.eks. med PBKDF2), så er det ikke så galt igen:

Md5+salt er vel sikkery nok. De skal blot invalidere de gamle koder med et nyt salt?

Nej. Selv om der er mindre chance for kollisioner, eller du bruger en funktion der itererer en hurtig hash-algoritme (som PBKDF2-HMAC-SHA1/2), kan du stadig udføre mange "gæt" per sekund. Er det bare MD5 kan du snildt lave mere end 60 milliarder gæt i sekundet på normalt hardware. Selv om PBKDF2 er langsommere kan du, da SHA-1/2 er hurtige og kræver meget lidt hukommelse, køre mange PBKDF2-funktioner samtidig. Salten er fuldstændig ligegyldig her--den hjælper kun mod pre-compute og nogle timing-angreb, ikke bruteforce/dictionary attacks af alle passwords under 8 tegn på under 15 sekunder (og du behøver ikke brute-force--se f.eks. Markov-cracking i John the Ripper: http://openwall.info/wiki/john/markov)

Dit bedste bud er bcrypt, hvis du vil have noget, der er let at bruge, eller scrypt, hvis du vil være fremtidssikker. (scrypt kan tunes til at kræve betydeligt mere hukommelse end bcrypt.)

Har skrevet lidt mere på Engelsk her.

"normalt hardware" AKA GPGPU'er. Men de kan jo også lejes på timebasis for småpenge hos Amazon.

For et læk som dette er brute-force næppe interessant for andet end [a-zA-Z0-9]{1,7} eller noget i den dur. En tilpas stor velkendt dictionary ville jeg gå efter. Og så er gennemsnitstiden man skal vente jo kun den halve.

@Patrick: Jeg forstår ikke konceptet med at tune MC-metoden til et sprog. Det skal vel gøres mod en forventet tilsvarende password dictionary; Rockyou, uniqpass, phpbb og venner.

Kort (og upræcist) om bcrypt og scrypt: bcrypt kan skrue på CPU. scrypt kan skrue på CPU og RAM. At skrue "nok" på RAM er ondskabsfuldt i den forstand at GPGPU'er skifter fra at være en maskinpistol til en forlader.

I mit hovede er en salt, pepper og scrypt en fornuftig løsning. Tilføj kryderier som autogenererede kodeord som default og check for om brugere ændrer passwords noget "svagt" (defineret som en kombination af længde, om det forekommer på nogle af de gængse dicts und so weiter).

@Patrick: Nu så jeg lige dit engelske skribleri (og kiggede bare lidt tilfældigt); "HMAC nonce on harddrive" er vel ikke et nonce — "Number to use ONCE" — det er en "secret common salt" AKA "pepper" (som bruges mange gange).

"normalt hardware" AKA GPGPU'er. Men de kan jo også lejes på timebasis for småpenge hos Amazon.

Ja, jeg vil sige at en GPU kvalificerer som "normalt hardware"--noget de fleste har adgang til, og som er billigt (sammenlignet med et rigtigt ASIC/en FPGA.)

Jeg forstår ikke konceptet med at tune MC-metoden til et sprog. Det skal vel gøres mod en forventet tilsvarende password dictionary; Rockyou, uniqpass, phpbb og venner.

Hvorfor ikke? Hvis du ved at der er meget større chance for, at 'h' kommer efter 'w' end 'v', så kan du lave mere kvalificerede gæt end brute force, uden at behøve nogen wordlist. Ligeledes hvis du ved, at 'a' ofte bliver skiftet ud med '4', 's' med '5', osv.

@Patrick: Nu så jeg lige dit engelske skribleri (og kiggede bare lidt tilfældigt); "HMAC nonce on harddrive" er vel ikke et nonce — "Number to use ONCE" — det er en "secret common salt" AKA "pepper" (som bruges mange gange).

Nej, det er ikke en "rigtig" nonce, men nu er det heller ikke f.eks. et stream cipher vi taler om. Det ville ikke give ret meget mening at bruge en ekstra parameter, som du smider væk. Som der står lige efter:

"If you are using an application which communicates with a database, and especially if there are other applications using the same database which you do not have control over, consider adding an extra secret: Generate a long, random value—or "pepper"—to use in HMAC(userpassword, pepper), and store the pepper (not the HMAC digest) on the disk or in your application itself, then store e.g. bcrypt(hmacdigest) in the database. Even if your database is compromised, or a weakness is found in bcrypt that might leak information about its password, an attacker won't be able to do much with your digests."

Hvorfor skulle Markov-kæden tilpasset dansk passe bedre på én gruppe kodeord end hvis Markov-kæden er tilpasset norsk? Eller engelsk? Det bedste match får man vel når man vægter sandsynlighederne efter en password dict — præcis så man også får 7 efter e med næsten samme sandsynlighed som t.

En "falsk" nonce ... :-)

Det bedste match får man vel når man vægter sandsynlighederne efter en password dict

Du får et match mod svage passwords, og meget få mod faktisk tekst/passphrases.

En "falsk" nonce ... :-)

Brug lidt mere tid på at læse hvad du retter, og lidt mindre på nitpick.