patrick mylund nielsen bloghoved

Skift også dit Last.fm-password

Det ser ud til, at hash digests fra Last.fm, ikke bare LinkedIn, også er blevet kompromitteret. Last.fm har skrevet følgende advarsel.

Ifølge personen, der udviklede Last.fm's password-autenticering blev der lagret usaltede MD5-digests, og lækagen kan have sket for en del tid siden.

Ifølge KoreLogic, der blandt andet afholder sikkerhedskonferencen DEF CON's password-cracking-konkurrence, er der tale om over 17.3 millioner unikke MD5 digests (det vil sige unikke passwords, så fra mange flere brugere), hvoraf 16.4 (95%) allerede er cracked.

Surt show.

Kommentarer (27)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Nicolai Hansen

Er jeg den eneste som synes 95% succesfuld cracking ratio lyder ret godt klaret? Men igen, det kan vel også vendes om og betyde at ca 1 mio personer har benyttet et meget stærkt password, ud af Last.fm's 30 mio brugere.
En mere detaljeret analyse af de crackede passwords kan findes her:
http://www.reddit.com/r/netsec/comments/upyu4/lastfm_password_security_u...

"Ifølge personen, der udviklede Last.fm's password-autenticering blev der lagret usaltede MD5-digests,"

Og hans "forsvar":

"In my defence: I was 18. It was 2003. The PHP community had no idea of bcrypt then."

Okay, han var ung og kendte sikkert intet til kryptografi, men hvordan kan siden vokse til >30 mio brugere, uden at det bliver opdaget? Vil det virkeligt sige at ikke én person, med bare en lille smule viden inden for emnet, har kigget koden igennem? Foruroligende!

  • 6
  • 0
Patrick Mylund Nielsen

Det var også min umiddelbare tanke, men givet nok tid, noget så svagt som MD5 (usaltet og ikke-itereret), og Hr. og Fru. Last.fm' password-kultur, er det måske ikke så overraskende.

Jeg kan godt forstå uvidenhed--jeg har da også skrevet software, der brugte en ret dårlig MD5-konstruktion for mange år tilbage--men som du siger er det uforståeligt, at det ikke er blevet opdaget. Og der har jeg svært ved at have sympati for firmaet. En sådan "ommer" kan koste folk deres bankkonti, privatliv, og forstand. Det er uansvarligt og uforsvarligt.

  • 1
  • 0
Peter Lind

Så længe der ikke bruges salts, så er det for så vidt ligegyldigt hvilken hashing rutine du bruger - average joe vil stadig bruger 123456 og password som kodeord. Og det er det ikke svært at lave rainbow tables til, ligegyldigt hvad du så bruger af algoritme.

Ligegyldigt hvad er sikkerheden aldrig bedre end det svageste led.

Derudover: hvilken dårlig kultur er det du ser i lastpass? I kraft af det tilbyder dig at generere dine passwords for dig så du ikke selv fylder 123456 ind så er sikkerheden alt andet lige kraftigt forbedret (selvom de burde ændre længden på default kodeord).

  • 0
  • 0
Deleted User

Hvad skal jeg gøre for at højne sikkerheden i min egen (web)applikation? Jeg ved godt hvordan jeg gør det nogenlunde sikkert, men har jeg mon overset noget? Jeg vil ikke stå med p**ke* i postkassen. Kan du komme med en "simpel" opskrift på hvordan jeg gør det bedre, hvis vi antager at jeg gemmer usaltede, ikke itererede MD5-kombinationer i en database.

  • 1
  • 0
Søren Louv

hvis vi antager at jeg gemmer usaltede, ikke itererede MD5-kombinationer i en database

Et kort svar: don't do it. Det er fuldstændig no go at opbevare usaltede hashes.

Hvis du ønsker en nem, sikker løsning, og du ikke selv har den fornødne erfaring, bør du benytte et framework, der håndterer sikkerheden for dig. Det er ikke en bulletproof løsning, men en god start.

  • 0
  • 0
Søren Louv

Du spørger hvordan man gør det bedre end LinkedIn og Last.fm: ved IKKE at opbevare hashes usaltede. Der er tusindvis af andre sikkerhed-meassures som ingen mening giver at liste op her.
Jeg har ingen anelse om, hvordan hackerne har fået adgang til password dumpet. Sql-injections; social engineering; insiders; zero day exploits eller tusind andre muligheder.

De fleste frameworks vil tilføje en salt til passwords inden de bliver hashet, og derved give en basal sikkerhed, som store virksomheder tilsyneladende mangler.

  • 1
  • 0
Patrick Mylund Nielsen

> Derudover: hvilken dårlig kultur er det du ser i lastpass?

Beklager. Jeg ved ikke hvorfor, jeg skrev LastPass. Jeg mente Last.fm. Jeg har ikke noget imod LastPass' password-kultur! Alt jeg mente var, at Last.fm-brugere nok ikke har generelt stærke passwords.

> Jeg har den fornødne viden, men det kunne da være rart at høre hvordan man løste Last.fm eller Linkedin's problem, i stedet for bare at skrive, at det er en dårlig måde at gøre det på.

Det er godt nok et stort spørgsmål at svare på, men én ting, der ville have gjort det mindre alvorligt, ville være hvis de havde brugt en itereret (stretched) og salted hashing-algoritme. Det kunne være PBKDF2-HMAC-SHA-1 til 512 med mange rounds eller mere intensive operationer som bcrypt eller scrypt (der tager meget hukommelse, så er svær at parallelisere på f.eks. GPUs eller FPGAs) med en høj work factor. De to store problemer med den måde, disse firmaer har gjort password-autenticering på er, at det er for let at genkende deres digests, og for let at gætte nye hurtigt.

(Det er for brugerne ret irrelevant om det tager 0.0001 sekund at generere et digest, eller om det tager 1 sekund, men det gør jo en kæmpe forskel i, hvor let det er at brute force dem efter, de er kompromitteret.)

Det bedste ville måske være, at de havde lavet deres egen, ordentlige hash-konstruktion med beviste kryptografiske primitiver, men når man tænker på, at der blev brugt usaltet MD5 til at starte med, er det muligvist for optimistisk.

  • 0
  • 0
Nicolai Hansen

Når man tænker på at de benyttede sig af MD5(password), så er det bestemt alt for optimistisk at tro at de kan finde ud af at opfinde deres eget. Med mindre man har viden indenfor kryptologi, så skal man passe på med at "opfinde sit eget" :)

Martin Slot: Her er en (ud af mange) meget simpel måde:
Bruger logger ind med brugernavn/email og en kode (klartekst). Serveren henter det gemte hash og salt fra databasen (ud fra brugernavnet/email). Salt og hash varierer per bruger.
Derefter går serveren igennem et loop hvor: x1=hash(kode salt) og loopet består af 1000 gange x2=hash(kode salt x), x3=hash(kode salt x2) ...
Til sidst sammenligner man det gemte hash med hash(kode salt x1000) og matcher det, så bliver brugeren logged in.

Til valg af hash-funktion kunne blowfish være et helt fint bud. Lav selv en hastighedstest på hvor hurtig din server kan klare 1000 gange: blowfish(kode salt), og juster antallet sådan at det er så højt som muligt, uden at det bliver en flaskehals. Har man én bruger som logger ind per time, så kan man jo sagtens sætte tallet højt, men har man en svag server og mange brugere som hele tiden logger ind, så kan man være tvunget til at sætte tallet ned.

Hvis man bliver hacket, og ens database lækker, så kræver det nu 1000(000 ..?) hash operationer for at sammenligne ét klartekst kodeord med ét hash. I Last.fm tilfældet kan man hashe MD5("password") og sammenligne med hele databasen (det kræver kun én operation).

  • 0
  • 0
Patrick Mylund Nielsen

Det jeg--eller rettere phk i hans md5crypt EOL-besked--foreslog var sådan set det du skrev. Du har jo i dette eksempel "opfundet dit eget." Jeg mente ikke, at du skulle lave dit eget cipher eller din egen hash-funktion. Det ville være vanvittigt. Som Bruce Schneier godt kan lide at sige, "anyone who creates his or her own cryptographic primitive is either a genius or a fool. Given the genius/fool ratio for our species, the odds aren't very good."

Men du har fuldstændig ret i, at man skal passe på, hvis man ikke er helt sikker på, hvilke ikke-tydelige bivirkninger, det kan have. Jeg er ikke helt sikker på, om du faktisk mener Blowfish block-cipheret, eller Bcrypt-KDF'en, der bruger Blowfish's langsomme key schedule, men man skal generelt (med f.eks. MD5 eller SHA) passe på med at iterere en hash-funktion, især hvis den ikke i forvejen har specielt mange bits. Du mister lidt entropi for hver omgang i loopet. Det er nok også mest falsk tryghed at inkludere salten i yderligere iterationer da avalanche-effekten fra første kørsel i en ordentlig kryptografisk hash-funktion randomiserer resten tilstrækkeligt.

En konstruktion, der ikke mister en betydelig mængde entropi, er PBKDF2. Der laves (vha. HMAC) et ydre og indre "lag" med samme, eller to forskellige hash-funktioner.

"Adaptive Key Derivation Functions" som PBKDF2-HMAC-x, bcrypt og scrypt gør nøjagtig, hvad du beskriver, og er ofte meget lettere at bruge. bcrypt tager f.eks. bare en "work factor", f.eks. 12, og gemmer digests, der reflekterer hvilken work factor, der blev brugt, så du ikke senere behøver bekymre dig om, om brugere kan logge ind, hvis du øger den. Det kræver bare et par linjer i Python:

import bcrypt

def getDigest(password):  
    return bcrypt.hashpw(password, bcrypt.gensalt(12))

def isPassword(password, digest):  
    return bcrypt.hashpw(password, digest) == digest

(eller constcmp(x, digest), men det er ret ligemeget med bcrypt, der har en 128-bit salt). De, specielt scrypt, er også ofte designet til at være svære at parallelisere--noget, der har ret stor betydning nu hvor alle har en semi-vild GPU.

  • 0
  • 0
Hans Schou

Det er godt nok et stort spørgsmål at svare på, men én ting, der ville have gjort det mindre alvorligt, ville være hvis de havde brugt en itereret (stretched) og salted hashing-algoritme. Det kunne være PBKDF2-HMAC-SHA-1 til 512 med mange rounds


Så et godt forslag er så for PHP-apps at bytte MD5 ud med SHA-512? Og så ellers skrue op for 'rounds' indtil koden bliver langsom nok?

$ time php5 -r "echo crypt('tuborg', '\$6\$rounds=2000000\$salt\$').\"\n\";"   
$6$rounds=2000000$salt$ZHO396Ygyh/0ppYKbatVF7KKcCwAQWBKXrYwbIYQ1a9SjUpMRZ4FkZeiGsBdR6uqrTKvWn2rniUKBSFZBBxcV1  
   
real    0m1.342s  
user    0m1.328s  
sys     0m0.008s

Næste debat bliver vel så hvornår "salt" er godt nok. Det skal vel bare et eller andet tilfældigt, som ikke er brugt på systemet før, og så langt at det er unikt i systemet?

Denne er vel lige så god som så mange andre:

<?php  
$salt = substr(str_shuffle("abcdefghijklmnopqrstuvwxyz0123456789"), 0, 8);  
?>

Eksemplerne er skamligt planket fra PHP: crypt - Manual
(jvf. reglen om at man ikke må opfinde noget selv)

  • 0
  • 0
Patrick Mylund Nielsen

Ja. Selv om NIST anbefaler, at alle bruger mindst SHA-256, kan du egentlig stadig bruge MD5 og SHA-1 i diverse konstruktioner, f.eks. når du itererer med en salt, eller med HMACs. Men den største grund til at du skulle ville bruge noget lavere end eksempelvis SHA-512 er, at SHA-512 er for langsom--så der er ikke rigtig nogen grund til ikke at bruge den i denne sammenhæng--det kan jo være lige fedt om det er SHA-1 med 200k rounds eller SHA-512 med 150k.

Selv om jeg ville anbefale PBKDF2-HMAC-SHA2 som et minimum, er dit eksempel helt fint i praksis. Du mister en del entropi med PHP's crypt(), men med SHA-512 er det ligegyldigt.

Der er ét stort "men": str_shuffle bruger næsten helt sikkert ikke en crypto-PRNG. Jeg er ikke PHP-guru, men jeg vil skyde på, at der bruges Mersenne Twister, eller en anden meget hurtig PRNG. Problemet her er, at Mersenne Twister er fuldstændig deterministisk: Du kan forudsige alle dens output efter bare et par observationer, og hvis den ikke er seeded til at starte med, så behøver du slet ikke observere noget.

(Man kan godt mærke, at PHP's crypt() er ved at være gammel, når standarden er DES med en to-karakters-salt.)

Hvis du ikke har noget mod et tredjepartsbibliotek er phpass (http://www.openwall.com/phpass/) lavet af folk, der har fuldstændig styr på, hvad de laver. Det understøtter også bcrypt.

Ellers er det vigtigste at tilføje, at salten skal være fuldstændig tilfældig, genereret med en crypto-PRNG, og gerne >=128 bits (ca. 25 a-z,A-Z,0-9-ASCII-karakterer.)

I øvrigt godt password :)

Edit: Hov, jeg missede CRYPT_BLOWFISH. Det er Openwall's (phpass) bcrypt-implementation, så brug endelig den hvis du kører PHP 5.3 eller over, gerne med en cost-parameter >= 12.

  • 0
  • 0
Peter Lind

Der er ét stort "men": str_shuffle bruger næsten helt sikkert ikke en crypto-PRNG. Jeg er ikke PHP-guru, men jeg vil skyde på, at der bruges Mersenne Twister, eller en anden meget hurtig PRNG. Problemet her er, at Mersenne Twister er fuldstændig deterministisk: Du kan forudsige alle dens output efter bare et par observationer, og hvis den ikke er seeded til at starte med, så behøver du slet ikke observere noget.

Det er fuldstændig irrelevant, den bruges til at generere salt med. Salt skal være 100% unik - tilfældighed er ligegyldigt. Netop fordi at salts primære funktion er at gøre det hashede password unikt, så to identiske passwords ikke hashes til det samme.

Selv om en angriber vidste præcis hvornår et salt var genereret og dermed vidste hvad det var - så ville det ikke hjælpe angriberen. Og derfor gemmer man også sit salt enten med sin hash eller i et field ved siden af. En lækket database med hashes og salts giver ikke angriberen nogen fordel: du er nødt til at bruteforce fra bunden af.

  • 0
  • 1
Patrick Mylund Nielsen

Det er fuldstændig irrelevant, den bruges til at generere salt med. Salt skal være 100% unik - tilfældighed er ligegyldigt.

Selvfølgelig er det ikke irrelevant. Salts er ikke enten-eller. Det eneste de gør er at udvide rummet af muligheder. Hvis jeg kan regne ud hvilke salts du har brugt (det er ligemeget hvornår), er der betydeligt færre mulige kombinationer af salt+digest, og derfor er det betydeligt lettere at førud-udregne muligheder.

Det er farligt at insinuere, at du enten har salted eller ikke. Der er meget stor forskel på at bruge to-karakters-salts fra en ikke-seeded PRNG, og 20-karakters-salts fra en crypto-PRNG.

Jeg går ud fra, at du mener, at så længe du har en unik salt per bruger i din installation, så er det "ok", men det er altså en lille ting i forhold til, at man kan kompilere en liste over key:values for mange forskellige installationer, der har samme (svage) setup.

  • 1
  • 0
Peter Lind

Du har ret, det er ikke irrelevant. Du antydede til gengæld at fordi der er brugt en prng så er systemet usikkert, hvilket muligvis kan være tilfældet hvis du har adgang til password hash men ikke salt. Det har jeg til gengæld ret svært ved at se ske: hvis du har adgang til password hash, hashing-algoritmen, det specifikke mikrosekund der blev genereret et salt ... men ikke salt selv. Det slår mig som teori og ikke noget, der i praksis vil finde sted (men ret mig endelig hvis du har historier om andet).

I denne sag ville det ingen rolle spille om der var blevet brugt en 20-karakter lang streng som salt, genereret af en dårlig prng, eller om der var blevet brugt en 20-karakter lang streng genereret fuldstændig tilfældigt - så længe begge var unikke og ca. tilfældige. I begge tilfælde har du ét unikt keyspace per password. Og i begge tilfælde ville du have det salt, der var brugt til at hashe med, så du ville kunne tage de mest interessante password og køre et dictionary attack på dem.

Men det er selvfølgelig rigtigt at der er meget stor forskel på at bruge 2 bogstaver som salt og så 20+ tilfældigt udvalgte tegn. Jeg beklager hvis min kommentar pegede i retning af at der ikke var.

  • 0
  • 0
Peter Lind

Jeg går ud fra, at du mener, at så længe du har en unik salt per bruger i din installation, så er det "ok", men det er altså en lille ting i forhold til, at man kan kompilere en liste over key:values for mange forskellige installationer, der har samme (svage) setup.

Ja, hvis din salt-algoritme genererer samme salt for lign. brugere på flere installationer (i.e. første bruger begge steder har samme salt, anden bruger ligeledes, etc). Så er der et problem.

  • 0
  • 0
Patrick Mylund Nielsen

Du antydede til gengæld at fordi der er brugt en prng så er systemet usikkert, hvilket muligvis kan være tilfældet hvis du har adgang til password hash men ikke salt.

Ja. Et system, der bruger Mersenne Twister og en 20-karakters-salt er betydeligt svagere end et, med en rigtig crypto-PRNG som /dev/urandom. Er det ikke logisk, at det er betydeligt lettere at føropbygge en liste af mulige salts og digests, når du ved nøjagtig hvilke salts brugerne har fået i installationer, der bruger en (muligvist useedet) Mersenne Twister til at generere salts fra a-z0-9?

Igen, tænk mange installationer, og betydelige ressurser. Det handler ikke om timing, bare simpel matematik. 2^24 er mindre end 2^48.

Det slår mig som teori og ikke noget, der i praksis vil finde sted (men ret mig endelig hvis du har historier om andet)

Jeg vil gerne, at du bakker op for hvad du siger, da det er dig, der argumenterer for ikke at bruge en kryptografisk stærk nummer-generator i en kryptografisk konstruktion.

  • 0
  • 0
Peter Lind

Ja. Et system, der bruger Mersenne Twister og en 20-karakters-salt er betydeligt svagere end et, med en rigtig crypto-PRNG som /dev/urandom. Er det ikke logisk, at det er betydeligt lettere at føropbygge en liste af mulige salts og digests, når du ved nøjagtig hvilke salts brugerne har fået i installationer, der bruger en ikke-seeded Mersenne Twister til at generere salts fra a-z0-9?


Hvis du ikke har adgang til salt og enten står overfor at skulle gætte det eller at skulle generere rainbow tables for alle muligheder, så har du fuldstændig ret.

Anyway, jeg er uenig i at str_shuffle() og lign. per definition aldrig er "sikkerhed nok". I forhold til eksemplet ovenover, så er 8 karakterer fra a-z0-9 ikke et godt salt. Betyder det at du aldrig vil kunne lave en god algoritme, der gør brug af str_shuffle()? Det kommer an på resten af dit system: som jeg pointerede helt fra starten, så handler sikkerhed om det svageste led. Hvis du ikke er i en position til at kunne forudsige hvad str_shuffle gør, så er det irrelevant om den bruges.

Derudover er en kryptografisk rng at foretrække, hvis man har den (til gengæld er der så andre problemer forbundet med at urandom og lign, så vidt jeg kan forstå) - og det vil klart være at foretrække, at man bruger et godt library til den slags ting, frem for at rulle sin egen salt algoritme.

  • 0
  • 0
Patrick Mylund Nielsen

Derudover er en kryptografisk rng at foretrække, hvis man har den (til gengæld er der så andre problemer forbundet med at urandom og lign, så vidt jeg kan forstå)

Det største problem er faktisk at finde en sikker nummergenerator, men kører du Linux, BSD eller Windows er det nu let-tilgængeligt. Det næststørste er, at det tager meget, meget længere tid at få tilfældige bytes fra en CSPRNG end en normal PRNG fordi der skal lyttes til device timings osv., men det har næsten ingen betydning i en passwordautenticeringsmekanisme.

Anyway, jeg er uenig i at str_shuffle() og lign. per definition aldrig er "sikkerhed nok".

Jeg prøver ikke at bevise, at en deterministisk str_shuffle ikke gør noget, men det gør betydeligt mindre end en tilfældig version. Det farlige ved en deterministisk salt-generator--specielt i software, der bruges af mange--er, at længden af salten--den kan være 50 karakterer--stopper med at betyde noget i precompute-sammenhæng. Nu behøver en fjende ikke brute force 2^298/2 (umuligt med silicon-computere) per digest for at førudkalkulere rainbow tables, men kan bare replikere salt-generatoren/initieringsvektoren, hvorefter der ikke kræves brute force (af salten.)

som jeg pointerede helt fra starten

Det, du sagde fra starten, var, at det var "fuldstændig irrelevant." Det passer ikke, og det er vi nu enige om.

Hvis du ikke er i en position til at kunne forudsige hvad str_shuffle gør, så er det irrelevant om den bruges.

http://en.wikipedia.org/wiki/Security_through_obscurity

og det vil klart være at foretrække, at man bruger et godt library til den slags ting, frem for at rulle sin egen salt algoritme.

110% enig. At rulle sit eget er noget af det farligste du kan gøre. Det er så svært at tage alt i betragtning, især hvis du er en "one-man operation." Du er også oftest den eneste, der overhovedet kigger på din egen implementation.

Der findes mange rigtigt gode libraries, og de fleste operativsystemer har en solid CSPRNG. Det er helt klart det bedste valg hvis du ikke er kryptograf og har et gæng andre kryptografer, der vil kigge det igennem.

  • 0
  • 0
Peter Lind

Jeg prøver ikke at bevise, at en deterministisk str_shuffle ikke gør noget, men det gør betydeligt mindre end en tilfældig version. Det farlige ved en deterministisk salt-generator--specielt i software, der bruges af mange--er, at længden af salten--den kan være 50 karakterer--stopper med at betyde noget i precompute-sammenhæng. Nu behøver en fjende ikke brute force 2^298/2 (umuligt med silicon-computere) per digest for at førudkalkulere rainbow tables, men kan bare replikere salt-generatoren/initieringsvektoren, hvorefter der ikke kræves brute force (af salten.)

Ja, i det omfang du ved hvad seed var eller kender et salt og derfra kan regne dig frem til de næste. Gør du ikke det har du ingen fordel, for selv om den er deterministisk så kan du ikke forudsige næste værdi (medmindre selvfølgelig at den ikke blot ikke er deterministisk men også så dårlig at den begrænser mulighederne/ikke har en jævn distribution).

Det, du sagde fra starten, var, at det var "fuldstændig irrelevant." Det passer ikke, og det er vi nu enige om.

  1. juni kl.12.40:

Ligegyldigt hvad er sikkerheden aldrig bedre end det svageste led.

http://en.wikipedia.org/wiki/Security_through_obscurity

Det har intet med security through obscurity at gøre. Faktum er at hvis du ikke kan forudsige hvilket salt en given person får, så har du ikke indskrænket dit salt-keyspace.

Det er ligeså relevant for hele diskussionen som spørgsmålet om hvor du opbevarer dine salts. Hvis en angriber har adgang til både dine salts og dine hashede passwords, så er din perfekte rng ligegyldig. Det var det, der var min pointe med referencen til den tidligere kommentar.

I det hele taget er det meningsløst at diskutere udvalgte emner omkring sikkerhed: du kan have det perfekte setup med hashing via blowfish og 20+ karakterer tilfældige salts - men hvis du lader brugeren logge ind via http og dermed er vidt åben for MitM, så er du lige vidt.

Nå, jeg vil lade det ligge nu. Tak for diskussionen - jeg blev en anelse klogere, og jeg håber jeg ikke fik spildt din tid helt.

  • 0
  • 0
Patrick Mylund Nielsen

Gør du ikke det har du ingen fordel, for selv om den er deterministisk så kan du ikke forudsige næste værdi

At den er deterministisk betyder netop, at du kan forudsige efterfølgende værdier. Deterministiske PRNGs har ikke en tilfældig distribution i den sans.

Ligegyldigt hvad er sikkerheden aldrig bedre end det svageste led.

Fair nok, det sagde du tidligere. Men vi diskuterer nu PRNGs vs CSPRNGs, og du sagde, det var helt ligegyldigt hvad man brugte.

Det har intet med security through obscurity at gøre. Faktum er at hvis du ikke kan forudsige hvilket salt en given person får, så har du ikke indskrænket dit salt-keyspace.

Det er definitionen af security through obscurity. I stedet for at kræve, at en fjende brute forcer salts for at på forhånd bygge en dictionary, håber du, at de ikke finder ud af, hvilket karaktersæt du vælger dine salts' indhold fra, og hvilken IV (hvis nogen) du har givet din PRNG.

Det er ligeså relevant for hele diskussionen som spørgsmålet om hvor du opbevarer dine salts. Hvis en angriber har adgang til både dine salts og dine hashede passwords, så er din perfekte rng ligegyldig.

Ja, salts er fuldstændigt ligegyldige mod brute force/"after-the-fact"-angreb. Hvis jeg har givet indtrykket at jeg mente andet var det en fejl. Her er det key stretching og strengthening, der betyder alt.

setup med hashing via blowfish og 20+ karakterer tilfældige salts - men hvis du lader brugeren logge ind via http og dermed er vidt åben for MitM, så er du lige vidt.

Yep. Mens vi har diskuteret dette har fjenden lavet et timing-angreb mod dine brugerkontis navne for at finde en superuser, har googlet dem, og logget på deres konto med 10 kæledyr/kæreste-gæt plus et udråbstegn.

(Grunden til jeg personligt fokuserer meget på passwords er, at det er et sted hvor man sætter folks andre konti, kreditkort, privatliv, osv. på spil, hvis man ikke gør det rigtigt--ikke bare deres konto på ens egen side.)

Nå, jeg vil lade det ligge nu. Tak for diskussionen - jeg blev en anelse klogere, og jeg håber jeg ikke fik spildt din tid helt.

I lige måde! Jeg siger aldrig nej tak til lidt hjernegymnastik.

  • 0
  • 0
Patrick Mylund Nielsen

I samme åndedrag kan nævnes, at også League of Legends er blevet hacket

Imponerende.

Gad vide om firmaer vælger at offentliggøre disse ting nu, hvor folk allerede har fået nok af at høre om password-lækage.

"@crackmeifyoucan here again.
LOL list was leaked a long time ago. Its hashed with sha256. And is approx 1.6 million unique hashes. It is approx 80% cracked as far as I know. The string "lol" is highly represented in the list which always made me THINK it was from this site. But I never knew it for sure."

  • 0
  • 0
Nicolai Hansen

"Please use a good password. We compared encrypted password hashes and discovered that 11 passwords were shared by over 10,000 players each. A double-digit percentage of individuals had the same password as at least one other person." - aka de brugte ingen salts... og så hjælper SHA2 jo desværre ikke alverdens meget.

  • 0
  • 0
Log ind eller Opret konto for at kommentere