Last.fm bekræfter lækage af adgangskoder

Med alle disse password lækager kan man undre sig over om der er nogen lækager som ikke bliver offentliggjort...

dvs. er der password tyverier vi ikke hører om ?..

Makes you paranoid, doesn't it ?

Jeg har stjålet Jan's koder! Dem alle sammen! Hahahah!..


... oh wait?

#1
Selvfølgeligt er der det. LinkedIn har stadigvæk ingen ide om hvordan deres passwords kom ud. Det var kun fordi de blev smidt ud til offentligheden at man blev opmærksom på det.

Koderne og Emails skal helt sikkert nok dukke op på PasteBin på et eller andet tidspunkt.

Håber det her fortsætter så folk kan få gang i stærke og unikke kodeord ^_^

#5
Jeg kan ikke helt se hvordan en stærk og unik adgangskode skulle hjælpe hvis adgangskoden er offentliggjort.

Jeg håber at det er med til at øge sikkerheden på nettet alle steder.

Jeg vil ikke have mine kodeord hapset, og jeg gider ikke ændre dem hver måned, seriously! Få nu styr på sikkerheden ffs.

#5
Det er nok mere hjemmesiderne der skal have stærkere og unikke sikkerhedsforanstaltninger. Du kan have verdens bedste kodeord, men det hjælper ikke hvis der er fri adgang til den database det ligger på.

Lagde mærke til denne bekræftelse på min egen Last.FM account i går og skiftede da også promte.
Nu hvor både LinkedIn og AS er blevet komprimeret, gad vide om twitter eller facebook står for skud næste gang

Hm, er det bare mig der mangler viden - eller plejer man ikke godt og grundigt at sikre mod dette ved ikke at gemme kodeord, men kun deres hashede værdi? Så vidt jeg ved kan man (hvis det er gjort ordentligt) ikke bruge den hashede værdi til fantastisk meget.

#6: "Få gang i" - altså fremadrettet.

#10

Problemet med LinkedIN (og måske de andre) er, at de gemte dem som en hashed værdi, men havde ikke gjort noget ekstra for at "forstærke" den hashede værdi. Så en bruteforce på de hashede værdier kunne hurtigt afsløre mange af de rigtige password.

wut, de opfordrer deres brugere til at ændre kodeord. Men har ikke gjort dem opmærksom på det?

Hvad med at sende en mail ud til brugerne. ??

#6

Det er den ikke. Det er hash af adgangskoden der er ude.

Ja jeg har i hvert fald ikke fået nogen mail fra Last.FM om at jeg bør skifte kode.

#12

Hvad du siger er at de bare har gemt dem med en gang hash, altså uden iterationer og uden salt værdier? Det lyder nu heller ikke specielt fornuftigt.

Så vidt jeg har læst mig til, så bør man tilføje minimum en 8 byte salt værdi og køre et tilfældigt antal iterationer over 1000. Hvis man samtidig påtvinger et kodeord på over 8 tegn, så burde man være uden for de fleste rainbow-tables, plus påtvinge majuskler og minuskler, special tegn og numeriske tegn.

Et kodeord med en længe på 8 eller færre tegn og kun påført en gang hash kan genfindes på meget kort tid via en rainbow table.

waterdog (6) skrev:

Jeg kan ikke helt se hvordan en stærk og unik adgangskode skulle hjælpe hvis adgangskoden er offentliggjort.

Så længe passwordet er hashet, så hjælper det gevaldigt. For sites som gemmer password i klartekst hjælper det ikke at lave det stærkere. Det hjælper altid at lave det unikt. Brugere som har brugt samme password til flere sites er altid mere udsatte når den slags sker.

MFRaver (12) skrev:

Problemet med LinkedIN (og måske de andre) er, at de gemte dem som en hashed værdi, men havde ikke gjort noget ekstra for at "forstærke" den hashede værdi. Så en bruteforce på de hashede værdier kunne hurtigt afsløre mange af de rigtige password.

At hashe passwordet er stadigvæk et væsentligt skridt fremad i forhold til at gemme det i klartekst. Selvfølgelig bør sites bruge salt. Men som bruger kan man beskytte sig imod manglende salt ved at bruge et stærkt password.

Vossen (16) skrev:

Så vidt jeg har læst mig til, så bør man tilføje minimum en 8 byte salt værdi og køre et tilfældigt antal iterationer over 1000.

Jeg vil sige 8 bytes er absolut minimum. Og 8 bytes er kun nok hvis det er en binær værdi. Er der tale om salt bestående kun af tal og bogstaver skal man op på minimum 11 tegn.

Hvad angår iterationer synes jeg til gengæld det er noget pjat at gå så højt op. Jeg har set et site der havde problemer med for meget CPU forbrug og langsomme logins fordi de havde for mange iterationer. Så vidt jeg husker var der tale om en værdi der blevet sat til 18 af en person der ikke vidste at systemet kun kørte iterationer som potenser af to og der dermed var tale om 2^18 iterationer.

En effektiv foranstaltning er en hvor angriberens resurseforbrug vokser hurtigere end legitim brug. Det vil sige at en foranstaltning hvor resurserne til legitim brug vokser lineært men resurserne til et angreb vokser kvadratisk eller eksponentielt er en effektiv foranstaltning.

waterdog (6) skrev:

#5
Jeg kan ikke helt se hvordan en stærk og unik adgangskode skulle hjælpe hvis adgangskoden er offentliggjort.

Der er rigtig mange der bruger det samme password over alt på nettet - jeg tror at det er det han håber at folk får øjne op for og sørger for at have unikke passwords de steder man surfer rundt på nettet.

Jeg bruger selv 1password (mac og windows samt android og iOS), til at lave unikke passwords de steder jeg færdes på nettet.

Skulle mit password være blandt de hackede, så er det "kun" det ene sted hvor det password bliver brugt (jeg har skiftet ved linkedin og last.fm) - og ikke alle steder.

Jeg har en kollega som bruger det samme password over alt - jeg tror desværre ikke hun gider at ændre den praksis...

morsing (13) skrev:

wut, de opfordrer deres brugere til at ændre kodeord. Men har ikke gjort dem opmærksom på det?

Hvad med at sende en mail ud til brugerne. ??

RichardDHammond (15) skrev:

Ja jeg har i hvert fald ikke fået nogen mail fra Last.FM om at jeg bør skifte kode.

De har også kun meldt det ud ved at have det stående øverst på deres hjemmeside.
Generelt har de ikke meldt specielt meget ud.

kasperd (17) skrev:

Hvad angår iterationer synes jeg til gengæld det er noget pjat at gå så højt op. Jeg har set et site der havde problemer med for meget CPU forbrug og langsomme logins fordi de havde for mange iterationer. Så vidt jeg husker var der tale om en værdi der blevet sat til 18 af en person der ikke vidste at systemet kun kørte iterationer som potenser af to og der dermed var tale om 2^18 iterationer.

Nu er der også forskel på 1000 og 262144 iterationer, jeg ved det ikke selv, men hvor højt synes du man burde gå op? Det med 8 bytes har du nok ret i, det jeg har arbejdet med var nu også Java med byte arrays fra SecureRandom biblioteket. Iterationerne skete også på klientsiden da serveren ikke skulle kende til den uhashede data.

Vossen (20) skrev:

Nu er der også forskel på 1000 og 262144 iterationer

Det er der. Men det ændrer dog ikke på at jeg synes principielt man bør undgå at spilde CPU tid. En ændring der øger resurseforbrug på legitim brug og på angreb med samme faktor er ikke nogen fantastisk opfindelse. En ændring der øger resurseforbruget på angreb hurtigere end på legitim anvendelse er til gengæld et skridt i den rigtige retning.

Vossen (20) skrev:

hvor højt synes du man burde gå op?

Jeg ser ingen grund til at gå op til mere end f.eks. 4. Set med mine øjne drejer det sig bare om at beskytte sig imod kryptoanalyse af hashfunktionen selv. SHA1 har f.eks. 80 runder, der er fundet en svaghed ved 73 runder. Gentager man hash funktionen flere gange opnår man noget af den sikkerhed der ville have været hvis hash funktionen havde haft flere runder.

Det er ikke ualmindeligt at se en faktor to mellem antallet af runder hvor der er kendte svagheder og det faktiske antal runder. At man ikke sørger for at gøre den faktor større fra start af ved at lave flere runder er udelukkende at forbedre performance.

Til anvendelser indenfor password hashing ville det ganske rigtigt være bedre med en hash funktion der havde 2-3 gange så mange runder. Men hvis blot man hasher fire gange, så tror jeg ikke man behøver bekymre sig om svagheder i hashfunktionen. Det er alligevel ikke password hashing der er det første mål når en hashfunktion bliver brudt. Der er mange andre anvendelser af hashes, som er nemmere mål.

Jeg synes i stedet man bør se sig om efter andre metoder til at forstærke sikkerheden.

Et interessant spørgsmål jeg så komme frem i forbindelse med linkedin fadæsen var om man kunne offloade noget af beregningen til javascript på klienten. Problemet er at hvis man øger CPU forbruget til passwordvalidering med en faktor tusind på serveren, så bliver den et lettere mål for DoS angreb. Kunne man i stedet flytte den tunge del af beregningen over på klienten og gøre det i javascript, så ville serveren ikke være så udsat.

Jeg tror jeg er tæt på at have en metode til at flytte noget af beregningen ud på klienten på en måde som ikke udgør nogen trussel imod sikkerheden. Det eneste problem er at javscript ikke er det mest effektive sprog. Og at legitim brug anvender langsom javascript kode og angreb kan bruge optimeret maskinkode er en lidt uheldig situation.

Jeg har ikke kunnet finde nogen dokumentation af hvad der findes af features i javascript, som kunne hjælpe på det problem. En kryptografisk hashfunktion eller måske funktioner til at regne med store tal som foregik med native kode i en javascript fortolker ville gøre det noget nemmere at realisere den idé jeg har.

Dog tror jeg ikke idéen er dødfødt, selv hvis det skulle vise sig at man bliver nødt til at gøre det med fortolket kode.

Vossen (20) skrev:

Det med 8 bytes har du nok ret i

Og egentlig er der ikke ret meget grund til at holde sig til kun 8 bytes. Det er billigt at øge størrelsen. Men der er selvfølgelig ingen grund til at bruge et salt med højere entropi end hashværdien selv. SHA1 bruger f.eks. en 160 bits værdi, så der er intet at vinde ved at øge størrelsen på salt ud over 20 tilfældige bytes.

kasperd (21) skrev:

Et interessant spørgsmål jeg så komme frem i forbindelse med linkedin fadæsen var om man kunne offloade noget af beregningen til javascript på klienten.

Proof of concept