mboost-dp1
Fra LinkedIn's blog:
http://blog.linkedin.com/2012/06/07/taking-steps-t...
Der er divergerende holdninger til om der saltes eller ej og der er ingen indikationer på at de tilhørende brugernavne/mailadresser er blevet lækket sammen med koderne.
What is the deal? Hvad er 6 millioner passwords i en rainbow table værd, hvis ikke man ved hvad de er til? Så skal man bare bruteforce sig ind i LinkedIn med 6 millioner log-in forsøg for at finde den rigtige kode til en konto.... som om serveren vil tillade det.
http://blog.linkedin.com/2012/06/07/taking-steps-t...
Finally, our current production database for account passwords is salted as well as hashed, which provides an additional layer of security.
Der er divergerende holdninger til om der saltes eller ej og der er ingen indikationer på at de tilhørende brugernavne/mailadresser er blevet lækket sammen med koderne.
What is the deal? Hvad er 6 millioner passwords i en rainbow table værd, hvis ikke man ved hvad de er til? Så skal man bare bruteforce sig ind i LinkedIn med 6 millioner log-in forsøg for at finde den rigtige kode til en konto.... som om serveren vil tillade det.
Ovenstående analyse og vurdering har endvidere fået LinkedIn til at love, at firmaet i fremtiden vil tillægge et ekstra lag sikkerhed til sidens adgangskoder, hvorved de vil være bedre rustet mod fremtidige angreb.
Og så har de ansat Captain Obvious åbenbart, herligt...
Måske tiden også var til, at kigge på sikkerheden, så man måske helt kunne undgå situationer hvor millioner af kodeord blev lækket?
Nogen der kender noget mere til hvordan SHA1 er blevet "brudt"?
Mig bekendt er SHA1 en hash, og derfor en "one way" kryptering. Man kan altså ikke finde det oprindelige indhold i hash'en. Eneste måde at "bryde" den på er ved bruteforce.
Men det ligger måske i at da resultatet altid er 32 tegn (men jeg det er), og det derfor er muligt at flere koder kan give den samme hash værdi. Hvis nu algoritmen havde en fejl, som gjorde at de første 31 tegn altid blev den samme, ville mængden af unikke hashes være begrænset... Og der vil derfor være flere koder der generere den samme hash.
Hvis man bruteforcer sha1, vil man derfor ikke nødvendigvis får den oprindelige kode. Men bare en kode der generere den samme hash. Begge kode vil derfor kunne bruge i det angrebet system.
Altså mit password kunne være "hejmeddig" og generere en hash på "qwertyu"
Men "giddemjeh" generere også en hash på "qwertyu"
Og en hacker kunne lige så godt finde "giddemjeh" frem for "hejmeddig".
[Edit]
#4. Tak for info :)
Mig bekendt er SHA1 en hash, og derfor en "one way" kryptering. Man kan altså ikke finde det oprindelige indhold i hash'en. Eneste måde at "bryde" den på er ved bruteforce.
Men det ligger måske i at da resultatet altid er 32 tegn (men jeg det er), og det derfor er muligt at flere koder kan give den samme hash værdi. Hvis nu algoritmen havde en fejl, som gjorde at de første 31 tegn altid blev den samme, ville mængden af unikke hashes være begrænset... Og der vil derfor være flere koder der generere den samme hash.
Hvis man bruteforcer sha1, vil man derfor ikke nødvendigvis får den oprindelige kode. Men bare en kode der generere den samme hash. Begge kode vil derfor kunne bruge i det angrebet system.
Altså mit password kunne være "hejmeddig" og generere en hash på "qwertyu"
Men "giddemjeh" generere også en hash på "qwertyu"
Og en hacker kunne lige så godt finde "giddemjeh" frem for "hejmeddig".
[Edit]
#4. Tak for info :)
#3
http://en.wikipedia.org/wiki/Rainbow_table
de skulle have brugt denne teknik:
http://en.wikipedia.org/wiki/Cryptographic_salt
http://en.wikipedia.org/wiki/Rainbow_table
de skulle have brugt denne teknik:
http://en.wikipedia.org/wiki/Cryptographic_salt
SHA1-krypteringDet er der ikke noget der hedder. Rettelse indsendes øjeblikkeligt.
Nu fortæller flere eksperter så, at mere end 60 procent af disse passwords kryptering sandsynligvis allerede er blevet brudt, hvilket kun efterladder små 3 millioner af de stjålne passwords indtakte, mens mere end 3,5 millioner passwords er mistet.Til gengæld er der noget der tyder på at filen har bestået af en ordbog på 3,5 millioner ord og 3 millioner faktiske passwords. I så fald er det kun overlappet mellem de lækkede passwords og ordbogen, som er brudt.
Det vil sige at der kun er lækket 2936840 hashværdier og 670781 af dem er brudt, hvilket vil sige ca. 23%.
Er der nogen som har oplysninger som kan understøtte eller modbevise hypotesen om at filen består af en ordbog på 3,5 millioner ord og 3 millioner lækkede hashværdier?
Jeg fandt SHA1 af mit eget kodeord i den lækkede fil, uden salt. Så de har uden tvivl gemt passwords uden salt. Hvis de har indført salt længe før denne hændelse og det dermed kun er gamle passwords der findes i filen, så burde de for længst have været ude med en meget klar meddelelse om hvornår det blev introduceret. Og de burde have sendt en email til alle de brugere, der har passwords som er ældre end den dato. Denne email skulle opfordre til at ændre passwordet.MadiZone (1) skrev:Der er divergerende holdninger til om der saltes eller ej
SHA1 er ikke brudt. Men svage passwords kan brydes uanset hvordan der hashes.fennec (3) skrev:Nogen der kender noget mere til hvordan SHA1 er blevet "brudt"?
Output af SHA1 er 160 bits. Skrives det som hexadecimal bliver det til 40 cifre.fennec (3) skrev:Men det ligger måske i at da resultatet altid er 32 tegn
De eneste passwords der bliver brudt er dem som er for nemme at gætte, f.eks. fordi de er for korte. Sandsynligheden for at en bruger har valgt et password som hasher til samme værdi som et af de svage password der er blevet testet er for alle praktiske formål nul.fennec (3) skrev:Hvis man bruteforcer sha1, vil man derfor ikke nødvendigvis får den oprindelige kode.
#10
Jeg har meget respekt for dig og dine evner, så jeg kan ikke udelukke at jeg misforstået noget(selvom jeg tvivler stærkt).
Vil du gerne uddybe:
1. "enhemligetekst" hvad skal den udregnes udfra per bruger basis, og hvordan finder vi den igen når vi skal validere?
2. Hvis at der er appended den samme salt til alle hashes i databasen, hvordan invaliderer det så mindre precomputed rainbow tables, end hvis den er unik per bruger?( så længe salten er unik for databasen)
Jeg har meget respekt for dig og dine evner, så jeg kan ikke udelukke at jeg misforstået noget(selvom jeg tvivler stærkt).
Vil du gerne uddybe:
1. "enhemligetekst" hvad skal den udregnes udfra per bruger basis, og hvordan finder vi den igen når vi skal validere?
2. Hvis at der er appended den samme salt til alle hashes i databasen, hvordan invaliderer det så mindre precomputed rainbow tables, end hvis den er unik per bruger?( så længe salten er unik for databasen)
Mamad (moveax1ret) (12) skrev:1. "enhemligetekst" hvad skal den udregnes udfra per bruger basis, og hvordan finder vi den igen når vi skal validere?
Den gemmes også i databasen.
Mamad (moveax1ret) (12) skrev:2. Hvis at der er appended den samme salt til alle hashes i databasen, hvordan invaliderer det så mindre precomputed rainbow tables, end hvis den er unik per bruger?
De beskytter lige godt mod precomputed rainbow tables.
Men forskellig salt beskytter bedst mod brute force.
Med ens salt så udregner man hash(salt + nemt password) og så finder man de brugernavne som har det hash.
Med forskellig salt skal man generere hash(salt + nemt password) for hvert brugernavn.
arne_v (13) skrev:Den gemmes også i databasen.
Så det du siger er at du vil gemme salten i databasen ved siden af hashen og brugernavnet?
#15
http://en.wikipedia.org/wiki/Salt_%28cryptography%...
http://en.wikipedia.org/wiki/Salt_%28cryptography%...
In a typical usage for password authentication, the salt is stored along with the output of the one-way function, sometimes along with the number of iterations to be used in generating the output (for key stretching).
#17
At gøre det på den måde vil vel kun gøre det umuligt at finde dubletter blandt passwords?
Det er lidt højere sikkerhed, men vel næppe meget mere?
Hvilket kryptografisk angreb er det helt præcist man afværger ved at saltet er unikt per hash?
At gøre det på den måde vil vel kun gøre det umuligt at finde dubletter blandt passwords?
Det er lidt højere sikkerhed, men vel næppe meget mere?
Hvilket kryptografisk angreb er det helt præcist man afværger ved at saltet er unikt per hash?
arne_v (17) skrev:In a typical usage for password authentication, the salt is stored along with the output of the one-way function
Jeg vil mene at det både kan tolkes som at saltet stores som en del af den serverside kode der inputter passwordet i DBen, ikke nødvendigtvis at der er et unikt salt per hash.
#20
Almindeligt dictionary og brute force. Og man afværger det ikke - man gør det bare dyrere.
Hvis du har et dictionary med N meget brugte passwords og 1 salt, så beregner du hash(salt + password) ialt N beregninger og søger efter de beregenede hash værdier i de faktiske hash værdier.
Hvis du har et dictionary med N meget brugte password og et random per bruger salt med M mulige værdier skal du lave ialt M*N beregninger.
"N meget brugte passwords" kan naturligvis erstattes med "N mulige passwords af længde <= K".
Almindeligt dictionary og brute force. Og man afværger det ikke - man gør det bare dyrere.
Hvis du har et dictionary med N meget brugte passwords og 1 salt, så beregner du hash(salt + password) ialt N beregninger og søger efter de beregenede hash værdier i de faktiske hash værdier.
Hvis du har et dictionary med N meget brugte password og et random per bruger salt med M mulige værdier skal du lave ialt M*N beregninger.
"N meget brugte passwords" kan naturligvis erstattes med "N mulige passwords af længde <= K".
Næsten. Salt behøver ikke være hemmeligt. Det vigtige er at det er forskelligt for hver bruger. Her er et eksempel på hvordan det kunne se ud:fennec (6) skrev:Så hvis de havde lavet deres sha1() som:
sha1("enhemligetekst" + brugerens kode)
I ovenstående eksempel er der tre værdier adskilt af $http://www.cyberciti.biz/faq/understanding-etcshadow-file/ skrev:$1$fnfffc$pGteyHdicpGOfffXX4ow#5
1 - betyder at det er MD5
fnfffc - er salt værdien
pGteyHdicpGOfffXX4ow#5 er MD5 hashen skrevet i base64.
Dette format stammer så vidt jeg ved fra Linux, men bruges også på andre systemer. Man kan selvfølgelig også gøre det på andre måder. Hvis oplysningerne gemmes i en database kan man have en kolone til at angive type, en anden kolonne til at angive salt, og en tredje til at angive hash.
Det er netop pointen.Mamad (moveax1ret) (20) skrev:At gøre det på den måde vil vel kun gøre det umuligt at finde dubletter blandt passwords?
Tag nu det konkrete eksempel hvor der måske har været tale om 3 millioner lækkede hashværdier og 3½ millioner ord i ordbogen.
For at finde ud af om nogen brugere har brugt et password fra ordbogen, så beregner man alle 3½ million hashværdier af ordbogen, sorterer de 6½ millioner hashværdier og kigger efter dubletter. Dette tager ganske få sekunder.
Havde der i stedet været tale om 3 millioner lækkede hashværdier med 3 millioner forskellige salt værdier, så skulle man hashe hvert ord i ordbogen en gang med hver hashværdi.
Det vil sige at kompleksiteten af angrebet stiger fra 3½ millioner SHA1 beregner til 3½ billioner SHA1 beregninger.
arne_v (22) skrev:#20
Almindeligt dictionary og brute force. Og man afværger det ikke - man gør det bare dyrere.
Okay, så er jeg med, det vil gøre bruteforce væsenligt langsommere- det har du ret i :)
Mamad (moveax1ret) (14) skrev:Så det du siger er at du vil gemme salten i databasen ved siden af hashen og brugernavnet?
arne_v (15) skrev:#14
Ja.
Ved oprettelse af brugernavn, så genererer man et random hash og gemmer sammen med resten af bruger informationen.
Det er vist helt standard.
Men hvis hackeren udtrækker data, fx ved SQLi... Vil han så ikke ende med en liste, med brugernavn OG dertilhørende salt for hver bruger? - Hvilket vel eliminere salten?
#27
Nej jeg forstår at en salt ikke behøves at være hemmelig. Især hvis vi antager at
Hvis vores server bliver komprimiteret, kan hackeren finde salten alligevel (Altså selvom vi prøver at skjule den).
Men hemmelige salts er vel egentlig en ret god sikkerhed mod de SQL injections vi har set på det seneste? Antaget salten ikke er i databasen.
Omvendt set SQL sikkerhed er en god løsning mod SQLi...
Edit.: Det er æbler og pærer - Med hver sit formål, jeg forstår.
Nej jeg forstår at en salt ikke behøves at være hemmelig. Især hvis vi antager at
Hvis vores server bliver komprimiteret, kan hackeren finde salten alligevel (Altså selvom vi prøver at skjule den).
Men hemmelige salts er vel egentlig en ret god sikkerhed mod de SQL injections vi har set på det seneste? Antaget salten ikke er i databasen.
Omvendt set SQL sikkerhed er en god løsning mod SQLi...
Edit.: Det er æbler og pærer - Med hver sit formål, jeg forstår.
Efter at have kigget på forskellige links har jeg fundet en anden teori: https://news.ycombinator.com/item?id=4073309kasperd (5) skrev:Er der nogen som har oplysninger som kan understøtte eller modbevise hypotesen om at filen består af en ordbog på 3,5 millioner ord og 3 millioner lækkede hashværdier?
Hans teori er at de hashes hvor de første fem tegn er overskrevet med nuller er dem som allerede er brudt, og dem som ikke er overskrevet er dem som endnu ikke er brudt.
Den teori forklarer ikke hvorfor der er dubletter. En mulig forklaring på det er at når et password anvendt af flere brugere blev brudt blev der kun overskrevet ved en af brugerne, og ikke alle der havde passwordet. Men hvis der virkelig er tale om 670781 som er blevet anvendt af to brugere, så er det da fuldstændigt usandsynligt at der ikke blandt dem har været blot et password, som blev brugt af mere end to brugere.
Det kan være at imens der blev brute forcet passwords blev hashes opbevaret i en tabel med alle de dubletter der har været blandt passwords, men kun en blev overskrevet hver gang et password blev fundet. Og efterfølgende er denne liste blevet filtreret for dubletter.
Sidstnævnte er en plausibel hypotese som giver lige så meget mening som min oprindelige hypotese. Er her nogen som ved om der er systemer til brute forcing af passwords, som overskriver starten af hashværdien med nuller, når den er brudt?
Netop som jeg var midt i at skrive ovenstående indlæg kom der en email fra linkedin om at jeg skal skifte mit password.
Til gengæld er deres procedure for skift af password til grin.kasperd (31) skrev:Netop som jeg var midt i at skrive ovenstående indlæg kom der en email fra linkedin om at jeg skal skifte mit password.
Det er kun en SHA1 hash af mit password som er lækket, det er ikke lækket i klartekst. Det er stærkt nok til at det kommer til at tage lang tid før at det er brudt. Det vil sige at jeg er stadigvæk den eneste der kender det password. Såfremt det blot bliver skiftet indenfor en overskuelig fremtid har det altså intet at sige at en SHA1 værdi er lækket.
At jeg er i stand til at præsentere det korrekte password langt hurtigere end hackerne kan finde det ved brute force burde jo give en kraftig indikation om at jeg er den retmæssige ejer af det login.
Men ak nej, linkedin synes da overhovedet ikke at mit gamle password skal indgå i proceduren for at skifte password. I stedet anvendes der email sendt i klartekst.
... og selvom hackerne så får reverse-engineeret mange millioner hashes, så har de ingen specifikke konti at koble dem på. De har bare en liste med 6 millioner vilkårlige koder som de ikke kan bruge til noget som helst.
Så længe der ikke eksisterer en association mellem brugernavne og adgangskoder, så er adgangskoderne på grænsen til værdiløse.
Så længe der ikke eksisterer en association mellem brugernavne og adgangskoder, så er adgangskoderne på grænsen til værdiløse.
MadiZone (33) skrev:og selvom hackerne så får reverse-engineeret mange millioner hashes, så har de ingen specifikke konti at koble dem på. De har bare en liste med 6 millioner vilkårlige koder som de ikke kan bruge til noget som helst.
Bare fordi det der er leaked til offentligheden ikke indeholder andet end hashes er det på ingen måde ensbetydende med at hackerne ikke har flere data..........
Og i øvrigt "reverse engineerer" man ikke hashes......
http://en.wikipedia.org/wiki/Reverse_engineering
Da jeg undersøgte filen fandt jeg frem til 18 linjer som jeg synes ser usandsynlige ud pga. for mange nuller eller for mange gentagne tegn.
Jeg prøvede at søge efter dem på Google og fandt frem til at en af linjerne matchede Passw0rd.http://www.tozz.nl/temp/combo_not.zip skrev:000006e6c9dcd2bee466173bfae686191f4d1c4b
000007e698482b09e466173bfae68619200e31de
00000ae655e7272b92b9effc55224ebae22214d7
00000ae60770216a92b9effc55224ebae22214d7
e39fc7e643f7141e2943ae816376d83a8c92e364
d403cbe6e3a684b82943ae816376d83a8c92e364
000006e71a94ed6ad332b1162c20f86b84011dd2
000007e709afb02ed332b1162c20f86b84011dd2
000000000e0000000a0c0a000000000000000000
00a00000d00a00000a0c0a000000000000000000
0000a0000e0000000a0c0a000000000000000000
00000910077770c8340f63cd2dca2ac1f120444f
00000d675e5cd8175efe0cf9a06fb6c87114d0e2
8ad4bd675e5cd8175efe0cf9a06f00d90bf03d54
0000038463c67f749e22ad7a5898cf9e90c27b21
ebfc7910077770c8340f607a5898cf9e90c27b21
00000114d0e20000000000000000000000000000
b6c87114d0e20000000000000000000000000000
Den komplette SHA1 hash af Passw0rd er ebfc7910077770c8340f63cd2dca2ac1f120444f, når der også i filen står ebfc7910077770c8340f607a5898cf9e90c27b21 tror jeg simpelthen ikke på at det også er en SHA1 hash. De ligner hinanden for meget. Er der nogen bud på hvad forklaringen kan være på de linjer?http://www.zdnet.com/blog/security/25-most-used-passwords-revealed-is-yours-one-of-them/12427 skrev:Passw0rd 00000910077770c8340f63cd2dca2ac1f120444f
Er der nogen bud på hvad forklaringen kan være på de linjer?
Det undrede også mig, eftersom SHA1 strengen gerne skulle have en meget høj entropi -- gentagne "nuller" er temmeligt usandsynlige. Som flere har været inde på, er det nok teorien om at det er en test-database med rigtige + "test" entries.
Mvh,
https://lastpass.com/linkedin/ her kan man tjekke om ens kode er blevet leaked
#35 og #36 5 nuller indikerer at den hash er allerede blevet cracked
#31
hvis du læser den side som du linker til, vil du finde utallige kode eksempler på det
https://twitter.com/gsuberland/status/210615218076794880 skrev:More fun passwords from LinkedIn... rainbowbright, placenta, lemonparty, midgetporn, abortion, goatse. Who the fuck choses these passwords?
#35 og #36 5 nuller indikerer at den hash er allerede blevet cracked
#31
kasperd (31) skrev:Er her nogen som ved om der er systemer til brute forcing af passwords, som overskriver starten af hashværdien med nuller, når den er brudt?
hvis du læser den side som du linker til, vil du finde utallige kode eksempler på det
Det er der nogen som gætter på, men hvis du ser på de 18 linier som jeg fremhævede, så holder den teori ikke. Du vil finde flere par af linier som ligner hinanden for meget til at begge kan være SHA1 hashes. Men samtidigt starter begge linier med fem nuller, hvilket skulle betyde at der allerede er fundet inputs som afbilder til de pågældende værdier.adnim (37) skrev:5 nuller indikerer at den hash er allerede blevet cracked
Det vil jeg ikke tro på før jeg ser det. Vis mig passwordene svarende til de 14 af ovenstående linier som har fem nuller. Og der er altså også en linje med 36 nuller.
Samme side påstår at der ingen dubletter er. Jeg har ikke desto mindre fundet 670781 dubletter.adnim (37) skrev:hvis du læser den side som du linker til, vil du finde utallige kode eksempler på det
At nogen er i stand til at skrive et stykke kode nu som håndterer dette mærkelige format fortæller intet om hvorfor nogle af tegnene er overskrevet med nuller.
Hvor er det almindeligt kendte værktøj som allerede før denne liste blev lækket brugte fem nuller til at angive hvilke hashværdier der allerede er fundet et input til? Indtil nogen kan udpege det værktøj er alle forklaringer på de nuller udelukkende gætterier.
Her er en interessant artikel med nogle observationer som en person har gjort ved at undersøge denne lækkede fil.
Hun brugte et velkendt brute force værktøj ved navn "John the Ripper" og en lille smule opfindsomhed til at undersøge filen.
Værktøjet anvender en ordbog kombineret med nogle simple modifikationer af ord til at komme med realistiske gæt på passwords.
Forfatteren af artiklen havde ikke nogen særlig ny ordbog ved hånden, men fandt alligevel mange passwords. Hun prøvede efterfølgende at anvende de gættede passwords som en ordbog til endnu et gennemløb. Hvilket viste sig at være ganske effektivt.
På den måde lykkedes det hende at finde passwords konstrueret ved omskrivninger af linkedin, selvom den oprindelige ordbog ikke havde indeholdt linkedin.
Det viser at selvom man modificerer et ord til ugenkendelighed er det ikke nødvendigvis et godt password. Hvis du har fundet på en række måder at modificere ordet på, så vil alle de personer som har fundet på nogle af de samme måder hjælpe med at vise vejen hen til dit password.
Nogle af de passwords der blev fundet på denne måde er ikke overskrevet med nuller i starten i den lækkede fil. Hvis gættet på at disse nuller angiver hvad der allerede er brudt holder stik, så betyder det at antallet af brudte passwords nu er nået et stykke højere op end de 60%.
Hun brugte et velkendt brute force værktøj ved navn "John the Ripper" og en lille smule opfindsomhed til at undersøge filen.
Værktøjet anvender en ordbog kombineret med nogle simple modifikationer af ord til at komme med realistiske gæt på passwords.
Forfatteren af artiklen havde ikke nogen særlig ny ordbog ved hånden, men fandt alligevel mange passwords. Hun prøvede efterfølgende at anvende de gættede passwords som en ordbog til endnu et gennemløb. Hvilket viste sig at være ganske effektivt.
På den måde lykkedes det hende at finde passwords konstrueret ved omskrivninger af linkedin, selvom den oprindelige ordbog ikke havde indeholdt linkedin.
Det viser at selvom man modificerer et ord til ugenkendelighed er det ikke nødvendigvis et godt password. Hvis du har fundet på en række måder at modificere ordet på, så vil alle de personer som har fundet på nogle af de samme måder hjælpe med at vise vejen hen til dit password.
Nogle af de passwords der blev fundet på denne måde er ikke overskrevet med nuller i starten i den lækkede fil. Hvis gættet på at disse nuller angiver hvad der allerede er brudt holder stik, så betyder det at antallet af brudte passwords nu er nået et stykke højere op end de 60%.
http://www.net-security.org/article.php?id=1727 skrev:
This simple Linux command line:
echo -n MyPassword | shasum | cut -c6-40
Er der nogen lignende metode til windows?
Derudover har Linkedin meldt ud om der kunne være stjålet mere end de 6,5 millioner offentliggjorte passwords?
ignuz (41) skrev:Derudover har Linkedin meldt ud om der kunne være stjålet mere end de 6,5 millioner offentliggjorte passwords?
Der er meget få dubletter i forhold til hvad man ville forvente, så det kan meget vel være passwords for hele brugerbasen der er lækket.
ISCS (30) skrev:Men hemmelige salts er vel egentlig en ret god sikkerhed mod de SQL injections vi har set på det seneste? Antaget salten ikke er i databasen.
Jeg tror at det er ret sjældent at SQL injection bruges til at hente og vise data fra databasen med. De fleste view implementationer vil ikke vise ekstra data.
arne_v (43) skrev:Jeg tror at det er ret sjældent at SQL injection bruges til at hente og vise data fra databasen med. De fleste view implementationer vil ikke vise ekstra data.
Hvis at det er muligt at lave sql injections har de ikke brugt parameteriserede stored procedures, eller prepared statements........
Hvis de ikke har gjort det har de NÆPPE brugt views.....
Hvis et site er vulnerable for sql injections og f.eks. kører ms sql server er fremgangsmåden sikkert at de embedder en ekstra exec master.dbo.xp_cmdshell som en extra query efter ;
Den cmdshell, de kører kan så få eks, echo til en asp fil der sidenhen kan køre og dumpe alt data.
Mamad (moveax1ret) (44) skrev:Hvis at det er muligt at lave sql injections har de ikke brugt parameteriserede stored procedures, eller prepared statements........
Hvis de ikke har gjort det har de NÆPPE brugt views.....
Der har vel altid et view. Det er bare muligt at view, business logic og data access kode er i samme fil.
Mamad (moveax1ret) (44) skrev:
Hvis et site er vulnerable for sql injections og f.eks. kører ms sql server er fremgangsmåden sikkert at de embedder en ekstra exec master.dbo.xp_cmdshell som en extra query efter ;
Den cmdshell, de kører kan så få eks, echo til en asp fil der sidenhen kan køre og dumpe alt data.
Sagtens, men hvis de kan det så bør de også kunne zippe app op og downloade den.
Jeg tog den komplete liste af SHA1 hashes og saltede og hashede dem. På den måde har man en fil der kan distribueres og bruges til at afgøre om ens eget password er på listen af lækkede passwords uden at den samtidigt nemt kan bruges til brute force af den komplete database.
http://kasperd.net/~kasperd/linkedin-salted.zip.to...
Det er selvfølgelig ikke særlig relevant nu da listen af de usaltede SHA1 hashes cirkuleres på Internettet og alle passwords på listen alligevel allerede er blevet annulleret af linkedin. Så det er nok mest et proof-of-concept.
http://kasperd.net/~kasperd/linkedin-salted.zip.to...
Det er selvfølgelig ikke særlig relevant nu da listen af de usaltede SHA1 hashes cirkuleres på Internettet og alle passwords på listen alligevel allerede er blevet annulleret af linkedin. Så det er nok mest et proof-of-concept.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund