Chinees forum laat gegevens 40 miljoen gebruikers uitlekken
Hackers hebben toegang gekregen tot de database van het Chinese internetforum Tianya. Ze hebben de gegevens van 40 miljoen gebruikers gepubliceerd, waaronder wachtwoorden, die voor een groot deel niet versleuteld opgeslagen waren.
Het bekende Chinese forum heeft gebruikers op de hoogte gesteld en zijn verontschuldigingen aangeboden. De gegevens van 40 miljoen gebruikers liggen nu op straat, meldt China.org. In totaal heeft het forum 60 miljoen gebruikers.
De gepubliceerde gegevens omvatten ook wachtwoorden, waarvan een groot deel niet was versleuteld: alleen de wachtwoorden van gebruikers die zich na november 2009 geregistreerd hebben, waren versleuteld.
Vorige week werd een groot aantal hacks op Chinese websites gepleegd, waarbij de gegevens van nog eens 50 miljoen gebruikers werden ontvreemd, meldt de Shanghai Daily. Daaronder was de grote Chinese ontwikkelaarscommunity CSDN, waarvan de gegevens van zes miljoen accounts werden ontvreemd en gepubliceerd. De oorzaak van de megahacks is onbekend.
Reacties (63)
Een forum met 40 miljoen gebruikers? Dat moet dan het grootste forum ter wereld zijn.
Tianya staat niet eens op de lijst van BigForums: http://rankings.big-boards.com/?sort=members
Tianya staat niet eens op de lijst van BigForums: http://rankings.big-boards.com/?sort=members
In China gaat alles wat meer in het groot gezien het bevolkingsaantal daar...
Big-boards kent wel meer grote fora niet, dus dat zegt verder niet veel.
Big-boards kent wel meer grote fora niet, dus dat zegt verder niet veel.
Volgens wiki staat het op de 72 plek ter wereld qua fora.
https://en.wikipedia.org/wiki/Tianya_ClubTianya Club is an Internet forum in China; currently it is the 12th most visited site in the People's Republic of China and 72nd overall[1]. It was founded on 14 February 1999.
Nee, 72ste meest bezochte site, ook al zijn ze ondertussen gedaald.
http://www.alexa.com/siteinfo/tianya.cn
http://www.alexa.com/siteinfo/tianya.cn
Volgens het artikel heeft het forum 60 miljoen gebruikers. 
Van 40 miljoen zijn de gegevens uitgelekt:
Van 40 miljoen zijn de gegevens uitgelekt:De gegevens van 40 miljoen gebruikers liggen nu op straat, meldt China.org. In totaal heeft het forum 60 miljoen gebruikers.
Jammer dat niet vermeld wordt welke exploits / lek er gebruikt is. Anders hadden we er nog iets aan gehad. SQL injecties lijkt me, omdat ze de (waarschijnlijk op SQL gebaseerde) database in konden, maar zeker weet je het helaas niet.
Misschien zijn gewoon de login gegevens van de overheid gebruikt, daarmee kun je vast ook alles zien 
Dan hadden ze ook de versleutelde gegevens kunnen zien. 
Hoeft totaal niet, stel er is ergens een zwakke file upload naar de webroot, of een 'inbraak' op de mail van 1 van de developers en daarna standaard wachtwoord mss, of virusje/trojan die toegang gaf tot interne computers, kan echt van alles zijn 
Onbegrijpelijk dat er voor zo'n groot aantal accounts nog leesbare paswoorden in de databank zitten. Vanaf 2009 hebben ze de applicatie blijkbaar aangepast, dan is het toch een eitje om de bestaande paswoorden om te zetten naar een versleutelde versie?
Vond ik ook inderdaad raar, als je inlogged wordt je ingevoerde wachtwoord versleuteld en met de database vergeleken neem ik aan? Hoe doen ze dit dan met niet-versleutelde wachtwoorden?
Je vergelijkt ze gewoon met allebei.
Nog slechter. Dit wil dus zeggen dat ze wel moeite hebben gedaan om een paar regels code te kloppen als soort van workaround.
Ze hadden die tijd beter kunnen besteden om gewoon alle wachtwoorden die niet versleuteld waren met een update script automatisch om te zetten.
Dan hadden ze een minder erg lek gehad (in hoeverre een lek niet erg kan zijn natuurlijk).
Ze hadden die tijd beter kunnen besteden om gewoon alle wachtwoorden die niet versleuteld waren met een update script automatisch om te zetten.
Dan hadden ze een minder erg lek gehad (in hoeverre een lek niet erg kan zijn natuurlijk).
Nou ja, eitje.. eitje.. zijn toch weer 40 miljoen records
1 record of 40 miljoen records maakt geen verschil uit.
-> Men diende ongeveer 5 regels te schrijven in de scripttaal dat men gebruikte, om de bestaande paswoorden om te vormen naar encrypted versie.
Een beetje testen, databank backup voor de update, en voila ... Zoiets zou maximaal 5 minuten mogen gekosten hebben aan downtime.
Dit geeft gewoon aan, dat men de boel meer beveiligt heeft, maar dan men het de moeite niet vond om de oude paswoorden te beveiligen. En ik heb ook vragen hierover.
Ik neem aan dat men speciaal een aparte veld gebruikte voor de encrypted wachtwoorden op te slagen, of op één of andere manier aangaven in hun systeem, als ze het zelfde veld gebruikte, dat het om encrypted wachtwoord ging of niet.
Want anders zie ik niet in, hoe hun software kon controleren of het wachtwoord correct was of niet. Het systeem moest weten dat een bepaalde gebruiker gebruik maakte van een encrypted password. En welke mensen niet. Of ze moesten gewoon op datum aan het controleren geweest zijn: Iedereen voor November 2009 -> password_check functie, iedereen vanaf en na 2009, encrypted_password_check functie.
Wat ze ook deden, het zou sowieso meer code geweest zijn, voor te testen op de 2 toestanden. Ipv hun energie te steken in het encrypteren van de oude blanco wachtwoorden, en gewoon 1 routine te gebruiken.
Denk dat we kunnen spreken van een slechte aanpak...
-> Men diende ongeveer 5 regels te schrijven in de scripttaal dat men gebruikte, om de bestaande paswoorden om te vormen naar encrypted versie.
Een beetje testen, databank backup voor de update, en voila ... Zoiets zou maximaal 5 minuten mogen gekosten hebben aan downtime.
Dit geeft gewoon aan, dat men de boel meer beveiligt heeft, maar dan men het de moeite niet vond om de oude paswoorden te beveiligen. En ik heb ook vragen hierover.
Ik neem aan dat men speciaal een aparte veld gebruikte voor de encrypted wachtwoorden op te slagen, of op één of andere manier aangaven in hun systeem, als ze het zelfde veld gebruikte, dat het om encrypted wachtwoord ging of niet.
Want anders zie ik niet in, hoe hun software kon controleren of het wachtwoord correct was of niet. Het systeem moest weten dat een bepaalde gebruiker gebruik maakte van een encrypted password. En welke mensen niet. Of ze moesten gewoon op datum aan het controleren geweest zijn: Iedereen voor November 2009 -> password_check functie, iedereen vanaf en na 2009, encrypted_password_check functie.
Wat ze ook deden, het zou sowieso meer code geweest zijn, voor te testen op de 2 toestanden. Ipv hun energie te steken in het encrypteren van de oude blanco wachtwoorden, en gewoon 1 routine te gebruiken.
Denk dat we kunnen spreken van een slechte aanpak...
Ten eerste is het toch echt wel meer werk dan 5 regels , ten tweede kost het *veel* meer tijd dan 5 minuutjes kosten om alles te encoden (ook al hoeft dat dan natuurlijk totaal geen downtime te kosten), ten derde kan het best dat ze simpelweg schreven if(input.password == database.password or hash(input.password) == database.password) then logged in. Blijft natuurlijk jammer dan dat de moeite deden om het volledig door te trekken naar alle records, maar als het om (toentertijd) 40 miljoen records gaat kan ik me voor stellen dat je zegt van "dit is beter als niets, en het kost te veel werk om het ook voor oude records uit te voeren".
, ten tweede kost het *veel* meer tijd dan 5 minuutjes kosten om alles te encoden (ook al hoeft dat dan natuurlijk totaal geen downtime te kosten), ten derde kan het best dat ze simpelweg schreven if(input.password == database.password or hash(input.password) == database.password) then logged in. Blijft natuurlijk jammer dan dat de moeite deden om het volledig door te trekken naar alle records, maar als het om (toentertijd) 40 miljoen records gaat kan ik me voor stellen dat je zegt van "dit is beter als niets, en het kost te veel werk om het ook voor oude records uit te voeren".
40 miljoen records van een MD5 hash voorzien? Denk voor een beetje cluster (wat ze daar vast hebben) dat dat maar een paar seconden duurt hoor... Misschien een minuut.
[Reactie gewijzigd door FireDrunk op woensdag 28 december 2011 00:20]
Ik heb geen idee hoe je zit te coden, maar als je meer dan 5 regels nodig hebt om een simpel conversie te doen, van plain wachtwoorden, naar een hash, md5, of whatever je keuze is, dan ben je grondig fout bezig.
Je conversie algoritme zou automatische al in een functie aanwezig moeten zijn, en daarna is het een simpel van een letterlijk 5 regel code, om alle records te updaten. Een paar regels meer, als je "veilig" wilt spelen.
Echt waar, waar blijf je het vandaan halen, dat 40 miljoen records updaten zo een zwaar & langdurig werk is... Als je echt met zo krappe hardware zit, dat de hash generatie, custom encryptie, of whatever zo traag is, dan doe je gewoon dit op voorhand, met een tijdelijk tabel, waar de plain wachtwoord, en de uiteindelijke inzitten. En als dit gedaan is na een paar uren ( wat je geen tijd kost, want is niet dat gij manueel dat zit te doen ), blijft er enkel over om gedurende een paar minuten, de wachtwoorden over te zetten ( en natuurlijk enkel de intussen "aangepaste" plain wachtwoorden in die x tijd, te herdoen ).
Zoiets zou maximaal 30 minuten codering werk mogen kosten, en dan ben ik enorm genereus. Een programmeur die uren nodig heeft voor zoiets te doen noemt men geen programmeur.
Je oplossing 3:
Dit is gewoon ofwel LUI zijn als programmeur ofwel een baas hebben dat totaal geen benul heeft wat het woord beveilig inhoud, als deze toelaat dat maar een fractie van een beveiliging maatregel doorgevoerd word. Ik heb beide al genoeg tegengekomen tot op heden, en dit is een basis reden dat zoveel domme hacks op website gebeuren.
Als programmeur ben je niet een dom beestje dat enkel code moet produceren aan de lopende meter. Sommige bazen denke enkel in termen van: Hoe meer we opleveren, hoe meer we verdienen. Awel, zo een projecten worden na een paar jaar, al totaal onhandelbaar, dat men uiteindelijk meer tijd steekt in het repareren van de database data wegens fouten ( wat dan 1/3 van de werktijd kost ), men speelt dan ook nog eens 1/3 van de werktijd kwijt omdat de code zo een spaghetti geworden is, dan het niet meer doenbaar is.
Als je luiheid of gemakzucht toelaat in programmatie, dan zijn de gevolgen vaak desastreus, zeker voor grote projecten zoals dat. Als men 40 miljoen gebruikers records heeft, dan weet men dat de gevolgen beyond pijnlijk zouden zijn.
Als het probleem bij de baas zit, heb je 2 keuzes: Dring erop aan dat de beveiligingsaanpassingen gerespecteerd worden. Weigert men dit, zoek een andere baan, want dit is een bedrijf dat tegen de lamp gaat lopen, en dan komt de schuld op je nek terecht.
Hoeveel *** websites kan je op geen 5 minuten nog altijd hacken met SQL injecties. En dan spreken we soms niet eens van 5 jaar oude software.
Sorry, maar zoiets kan & mag gewoon niet gebeuren. Dit is echt een regelrechte schande, voor de programmeur die deze aanpassing deed. Je kan er gewoon niet naast kijken, 40 miljoen wachtwoord open en bloot.
En als je dan weet, dat een groot deel van de mensen nooit hun wachtwoord wisselen... De gevolgen van zo een hack zijn niet te overzien voor de slachtoffers.
Je conversie algoritme zou automatische al in een functie aanwezig moeten zijn, en daarna is het een simpel van een letterlijk 5 regel code, om alle records te updaten. Een paar regels meer, als je "veilig" wilt spelen.
Echt waar, waar blijf je het vandaan halen, dat 40 miljoen records updaten zo een zwaar & langdurig werk is... Als je echt met zo krappe hardware zit, dat de hash generatie, custom encryptie, of whatever zo traag is, dan doe je gewoon dit op voorhand, met een tijdelijk tabel, waar de plain wachtwoord, en de uiteindelijke inzitten. En als dit gedaan is na een paar uren ( wat je geen tijd kost, want is niet dat gij manueel dat zit te doen ), blijft er enkel over om gedurende een paar minuten, de wachtwoorden over te zetten ( en natuurlijk enkel de intussen "aangepaste" plain wachtwoorden in die x tijd, te herdoen ).
Zoiets zou maximaal 30 minuten codering werk mogen kosten, en dan ben ik enorm genereus. Een programmeur die uren nodig heeft voor zoiets te doen noemt men geen programmeur.
Je oplossing 3:
Dit is gewoon ofwel LUI zijn als programmeur ofwel een baas hebben dat totaal geen benul heeft wat het woord beveilig inhoud, als deze toelaat dat maar een fractie van een beveiliging maatregel doorgevoerd word. Ik heb beide al genoeg tegengekomen tot op heden, en dit is een basis reden dat zoveel domme hacks op website gebeuren.
Als programmeur ben je niet een dom beestje dat enkel code moet produceren aan de lopende meter. Sommige bazen denke enkel in termen van: Hoe meer we opleveren, hoe meer we verdienen. Awel, zo een projecten worden na een paar jaar, al totaal onhandelbaar, dat men uiteindelijk meer tijd steekt in het repareren van de database data wegens fouten ( wat dan 1/3 van de werktijd kost ), men speelt dan ook nog eens 1/3 van de werktijd kwijt omdat de code zo een spaghetti geworden is, dan het niet meer doenbaar is.
Als je luiheid of gemakzucht toelaat in programmatie, dan zijn de gevolgen vaak desastreus, zeker voor grote projecten zoals dat. Als men 40 miljoen gebruikers records heeft, dan weet men dat de gevolgen beyond pijnlijk zouden zijn.
Als het probleem bij de baas zit, heb je 2 keuzes: Dring erop aan dat de beveiligingsaanpassingen gerespecteerd worden. Weigert men dit, zoek een andere baan, want dit is een bedrijf dat tegen de lamp gaat lopen, en dan komt de schuld op je nek terecht.
Hoeveel *** websites kan je op geen 5 minuten nog altijd hacken met SQL injecties. En dan spreken we soms niet eens van 5 jaar oude software.
Sorry, maar zoiets kan & mag gewoon niet gebeuren. Dit is echt een regelrechte schande, voor de programmeur die deze aanpassing deed. Je kan er gewoon niet naast kijken, 40 miljoen wachtwoord open en bloot.
En als je dan weet, dat een groot deel van de mensen nooit hun wachtwoord wisselen... De gevolgen van zo een hack zijn niet te overzien voor de slachtoffers.
5 regels als alles goed geprogrammeert is... maar goed, als passwords op meerdere plekken in meerdere routines worden gechecked dan wordt het opeens erg lastig. Dan moet je impact analyses gaan maken etc...
Ik kan me heel goed voorstellen dat ze dan voor de weg met de minste impact gaan en stukje bij beetje alles upgraden. Zeker met 60 miljoen gebruikers.
Overigens is het heel makkelijk hoe jij het stelt, maar soms win je die discussie met je manager niet hoor. Ik had deze discussie ook met een project leider... hadden een site gemaakt die multiple points of entry hadden en meerdere combinaties van gegevens die konden leiden tot het inloggen. Als het puntje bij paaltje komt, dan dicteert de business wat er wel en niet komen gaat en niet de programmeur. Zeker in china, voor jou 1000 anderen.
Ik kan me heel goed voorstellen dat ze dan voor de weg met de minste impact gaan en stukje bij beetje alles upgraden. Zeker met 60 miljoen gebruikers.
Overigens is het heel makkelijk hoe jij het stelt, maar soms win je die discussie met je manager niet hoor. Ik had deze discussie ook met een project leider... hadden een site gemaakt die multiple points of entry hadden en meerdere combinaties van gegevens die konden leiden tot het inloggen. Als het puntje bij paaltje komt, dan dicteert de business wat er wel en niet komen gaat en niet de programmeur. Zeker in china, voor jou 1000 anderen.
Klopt, als je een stored procedure in sql propt dan, ja, kan het zelfs in 1 nette regel. Maar laten we realistisch zijn, ten eerste zul je never nooit dergelijke bewerkingen doen op productie doen, dus je zou een clone van de database willen opzetten, die hashen, nachecken en - provided dat je database dat aankan - alle transacties sinds de clone uitvoeren op de clone en daarna weer hashen en database switchen en gezien de bizarre hoeveelheid activiteit op een forum met 60mil gebruikers zal je waarschijnlijk nog voor een laatste maal van de inactieve database de laatste transacties moeten overzetten, want je kunt moeilijk een site met 60mil gebruikers zomaar eventjes offline halen. Het hashen zelf zal waarschijnlijk niet op een grote cluster gebeuren maar op een lokaal systeem waar de clone naar toe getrokken is, waar je dus absoluut niet die snelheden hebt die jij omschrijft.
Nu wat betreft de code zelf:
0 tot 2 regels voor het verbinden met de database in de meeste talen
1 regel include van password hashing library (behalve als je 1 of andere standaard functie gebruikt)
1 regel voor include van config file met salt key (mogelijk opgenomen in bovenstaande library)
1 regel variable def 'start'
1 regel voor start loop binnentrekken van data (je wilt niet 60 miljoen records in memory opslaan wat bij veel systemen anders zou gebeuren)
1 regel select statement naar variable schrijven (vanuitgaande dat het op sql gebasseerd is) ("select top 10000 id, password from users where id > start" of "select id, password from users where id > start limit 10000")
1 tot 2 regels uitvoeren van query en resultaat naar variable opslaan (tweede regel omdat in veel talen er nog een standaard nabewerkingen moet gebeuren op queries voordat ze bruikbaar zijn)
1 regel voor de loop over de records
1 regel voor het hashen van wachtwoord
1 regel voor schrijven van sql voor update statement (er van uitgaande )
1 regel uitvoeren bovenstaande sql
1 regel voor sluiten van de tweede loop
1 regel waar je start de waarde toekent van laatste id
1 regel voor sluiten van eerste loop
en dat is nog maar als je van de meest simpel-mogelijke opzet uitgaat die een applicatie kan hebben en tel je de regels aan code in de password hashing library ni eens mee.
Daarna, als je een taal met uitgebreide sessie mogelijkheden hebt gebruikt (zoals bijv. veel talen met java als basis) is het goed mogelijk dat zodra je inlogt dingen zoals wachtwoorden in de sessie worden opgeslagen (en jah, dat is alles behalve efficient, maar ik heb het toch vaak genoeg gezien), dus dan moet je ook nog een script schrijven wat de sessies van iedereen herschrijft zodra ze weer een request doen (of iedereen uitloggen... maar dat lijkt me geen goed plan met zoveel gebruikers). En nee, ik probeer hier absoluut niet te zeggen dat het OK is wat hier is gebeurd, maar om nou direct rond te gaan bazuinen dat het iets is wat je "zomaar eventjes" doet dan klopt dat simpelweg niet. De wijziging die ze gemaakt hebben is zo'n wijziging die je zomaar doet (wie weet is die ook maar eventjes snel gemaakt in een namiddagje), maar er komt nog heel wat bij kijken als je productie data wilt wijzigen. Een andere approach zou kunnen zijn dat je de passworden hashed onlogin wat op zich makkelijk is, en goed scaled, maar dan blijf je natuurlijk unhashed passworden hebben. Maja, al bij al zou het goed te doen moeten zijn allemaal in een dag werk, tenminste, als je infrastructuur een beetje netjes is en dingen zoals database clones en transaction logging een beetje netjes werken, anders zal je daar ook nog meer werk voor moeten doen of de hele site offline halen (waarbij je alsnog eerst een backup/kopie zou moeten trekken wat an sich al in de minuten tijd kan lopen (naja, als je alleen de user tabel zou kopie dan is dat minder als een gig aan data wat redelijk snel zou moeten gaan.)).
PS. Trouwens, ik ben doodop terwijl ik dit zit te schrijven en ik was van plan om te gaan slapen in de trein, maar kvoelde me verplicht op het bovenstaande te reageren maar het zou dus best kunnen dat er nog stomme fouten in zitten
Nu wat betreft de code zelf:
0 tot 2 regels voor het verbinden met de database in de meeste talen
1 regel include van password hashing library (behalve als je 1 of andere standaard functie gebruikt)
1 regel voor include van config file met salt key (mogelijk opgenomen in bovenstaande library)
1 regel variable def 'start'
1 regel voor start loop binnentrekken van data (je wilt niet 60 miljoen records in memory opslaan wat bij veel systemen anders zou gebeuren)
1 regel select statement naar variable schrijven (vanuitgaande dat het op sql gebasseerd is) ("select top 10000 id, password from users where id > start" of "select id, password from users where id > start limit 10000")
1 tot 2 regels uitvoeren van query en resultaat naar variable opslaan (tweede regel omdat in veel talen er nog een standaard nabewerkingen moet gebeuren op queries voordat ze bruikbaar zijn)
1 regel voor de loop over de records
1 regel voor het hashen van wachtwoord
1 regel voor schrijven van sql voor update statement (er van uitgaande )
1 regel uitvoeren bovenstaande sql
1 regel voor sluiten van de tweede loop
1 regel waar je start de waarde toekent van laatste id
1 regel voor sluiten van eerste loop
en dat is nog maar als je van de meest simpel-mogelijke opzet uitgaat die een applicatie kan hebben en tel je de regels aan code in de password hashing library ni eens mee.
Daarna, als je een taal met uitgebreide sessie mogelijkheden hebt gebruikt (zoals bijv. veel talen met java als basis) is het goed mogelijk dat zodra je inlogt dingen zoals wachtwoorden in de sessie worden opgeslagen (en jah, dat is alles behalve efficient, maar ik heb het toch vaak genoeg gezien), dus dan moet je ook nog een script schrijven wat de sessies van iedereen herschrijft zodra ze weer een request doen (of iedereen uitloggen... maar dat lijkt me geen goed plan met zoveel gebruikers). En nee, ik probeer hier absoluut niet te zeggen dat het OK is wat hier is gebeurd, maar om nou direct rond te gaan bazuinen dat het iets is wat je "zomaar eventjes" doet dan klopt dat simpelweg niet. De wijziging die ze gemaakt hebben is zo'n wijziging die je zomaar doet (wie weet is die ook maar eventjes snel gemaakt in een namiddagje), maar er komt nog heel wat bij kijken als je productie data wilt wijzigen. Een andere approach zou kunnen zijn dat je de passworden hashed onlogin wat op zich makkelijk is, en goed scaled, maar dan blijf je natuurlijk unhashed passworden hebben. Maja, al bij al zou het goed te doen moeten zijn allemaal in een dag werk, tenminste, als je infrastructuur een beetje netjes is en dingen zoals database clones en transaction logging een beetje netjes werken, anders zal je daar ook nog meer werk voor moeten doen of de hele site offline halen (waarbij je alsnog eerst een backup/kopie zou moeten trekken wat an sich al in de minuten tijd kan lopen (naja, als je alleen de user tabel zou kopie dan is dat minder als een gig aan data wat redelijk snel zou moeten gaan.)).
PS. Trouwens, ik ben doodop terwijl ik dit zit te schrijven en ik was van plan om te gaan slapen in de trein, maar kvoelde me verplicht op het bovenstaande te reageren maar het zou dus best kunnen dat er nog stomme fouten in zitten
[Reactie gewijzigd door David Mulder op woensdag 28 december 2011 08:09]
Je kan ook natuurlijk alles op 1 regel zetten achter elkaar Als de syntax maar klopt 
Als de syntax maar klopt 
Zoiets kan natuurlijk wel degelijk; zulke zaken zijn intussen gemeengoed geworden.Sorry, maar zoiets kan & mag gewoon niet gebeuren.
Dat het niet mag, daar heb je natuurlijk 100% geljik in.
Je verhaal van 30 minuten programmeren doet de werkelijkheid geweld aan en vermoeden dat het een probleempje van niks zou zijn geweest om het op te lossen. (Dat het opgelost had moeten worden, blijft echter wel als een paal boven water. Sterker nog, het probleem had nooit ontstaan mogen zijn.)
Als je code gevolgen heeft voor het inloggen (of ingelogd zijn) van 60 miljoen gebruikers, wil je zekerheid ten top.
Dat houdt niet in: 'pak of bedenk maar een stuk code en plemp dat er maar in en we zien waarschijnlijk dat het wel goed gaat'. Nee!
Je wilt je code laten bekijken door anderen. Je wilt er een nachtje over slapen - misschien heb je toch nog iets over 't hoofd gezien. Je wilt je code eerst in 't klein uittesten in een nagebouwde situatie. Daarna in de praktijk in het klein. Daarna bijvoorbeeld in groepen - afhankelijk van hoe e.e.a. allemaal (ook fysiek) is opgebouwd.
Hoe dan ook... Die 30 minuten programmeerwerk is veel te optimistisch (en is allesbehalve bepalend voor de duur van de werkzaamheden); zeker als je alle benodigde voorzichtheidsbeginsels in acht wilt nemen. Een klein foutje waardoor 40 miljoen mensen niet meer kunnen inloggen...? Voor je 't weet ben je 10 miljoen klanten kwijt aan een concurrerend forum.
[Reactie gewijzigd door kimborntobewild op woensdag 28 december 2011 10:56]
Gegevens van 40 miljoen personen... Is dit dan de grootste persoon gegevens hack die bekend is bij het algemene publiek?
Misschien wordt het in de toekomst verplicht voor bedrijven met grote databases om 'watermarks' (zoals vroeger gedaan werd bij landkaarten http://en.wikipedia.org/wiki/Cartography#Cartographic_errors) in de db's op te nemen en dat een overheidsinstelling elke grote transactie van gegevens controleert op diefstal. Bijvoorbeeld een aantal fake personen opnemen in de db, en op deze personen zoeken bij controle.
maar wat ga jij als een hacker in godsnaam doen met gegevens van 40 miljoen chinezen ?!?
De overige (1,330,044,605 as of mid-2010) zijn wel veilig
Misschien wordt het in de toekomst verplicht voor bedrijven met grote databases om 'watermarks' (zoals vroeger gedaan werd bij landkaarten http://en.wikipedia.org/wiki/Cartography#Cartographic_errors) in de db's op te nemen en dat een overheidsinstelling elke grote transactie van gegevens controleert op diefstal. Bijvoorbeeld een aantal fake personen opnemen in de db, en op deze personen zoeken bij controle.
maar wat ga jij als een hacker in godsnaam doen met gegevens van 40 miljoen chinezen ?!?
De overige (1,330,044,605 as of mid-2010) zijn wel veilig
Een hacker doet er verder niks mee. Als je er iets misdadigs mee doet, dan ben je niet langer een hacker maar een cracker of gewoon een ouderwetse crimineel.maar wat ga jij als een hacker in godsnaam doen met gegevens van 40 miljoen chinezen ?!?
Een hacker is nl. iemand die er per definitie niks kwaads mee doet. Zodra je dat wel doet, ben je geen hacker meer maar een cracker. Of zo je wilt: een black hat hacker (versus een white hat hacker). Maar dat onderscheid moet je eigenlijk wel maken als je louter over 'hackers' spreekt.
Ten eerste: die 1,33 miljard zijn natuurlijk geen lid van het betreffende forum...De overige (1,330,044,605 as of mid-2010) zijn wel veilig
Ten tweede: dan heb je toch niet goed gelezen. Want naast deze 40 miljoen gebruikers zijn er recent nog eens de gegevens van 50 miljoen gebruikers (en kan natuurlijk een paar miljoen overlap zijn) van andere sites gelekt. En dat zijn alleen de bekende hacks.
[Reactie gewijzigd door kimborntobewild op woensdag 28 december 2011 11:05]
Da's nog eens een hack, 40 miljoen mensen, dat is 0,61% van de wereldbevolking (bron)
De aantallen zijn enorm, maar moeten misschien in perspectief worden gezet. De populatie van China is rond of over de miljard. Wanneer, zeg 20% van de populatie, internet heeft en daarvan een deel op fora komt die slecht beveiligd zijn...en het wordt gehackt, dan kan dit het resultaat zijn.
Niettemin: het is een behoorlijke hack!
Niettemin: het is een behoorlijke hack!
Maak er maar ruim over de miljard van.
Je ligt een jaartje of 30 jaar achter, hoorDe populatie van China is rond of over de miljard.
. In 1981 waren er al 1 miljard Chinezen, volgens de tellingen. Momenteel heeft China ongeveer 1,346 miljard inwoners.Hoeveel GIG/TERRA bytes aan data is dat wel niet?
80 Megabyte
40 voor paswoorden en 40 voor usernames.
40 voor paswoorden en 40 voor usernames.
Als ze allemaal 1 byte lang zijn wel ja...
40 000 000 * 40 bytes = 1.49011612 gigabytes
Random schatting als gebruikersnaam 10 bytes aan gegevens is, password 10 bytes, en nog 20 bytes aan andere account gegevens (instellingkjes, timezone, dat soort meuk). Daar komt dan nog een index op de username kolom bij, wat misschien uitschiet naar 2gb tot 2.5gb schat ik zo met de losse hand.
Het wordt leuker als je bedenkt dat de gemiddelde gebruiker misschien 30 berichtjes heeft geplaatst van ieder 200 karakters gemiddeld
60 000 000 * 30 * (200 bytes) = 0.327418093 terabyte
maar blijft op zich best weinig. Voeg daar aan toe dat misschien 1 op de 10 een avatar hebben geupload van laat ik zeggen 50 kb gemiddeld
60 000 000 * .1 * (50 kilobytes) = 0.279396772 terabyte
Hmm, valt nog steeds allemaal wel mee AFTER THOUGHT: chinese karakters... maken die de opslag nou efficiënter of minder efficient 
logisch gezien zou ik zeggen efficiënter (het is alsof je de taal zelf zipped) maar intuïtief zou ik zeggen minder efficient 
Random schatting als gebruikersnaam 10 bytes aan gegevens is, password 10 bytes, en nog 20 bytes aan andere account gegevens (instellingkjes, timezone, dat soort meuk). Daar komt dan nog een index op de username kolom bij, wat misschien uitschiet naar 2gb tot 2.5gb schat ik zo met de losse hand.
Het wordt leuker als je bedenkt dat de gemiddelde gebruiker misschien 30 berichtjes heeft geplaatst van ieder 200 karakters gemiddeld
60 000 000 * 30 * (200 bytes) = 0.327418093 terabyte
maar blijft op zich best weinig. Voeg daar aan toe dat misschien 1 op de 10 een avatar hebben geupload van laat ik zeggen 50 kb gemiddeld
60 000 000 * .1 * (50 kilobytes) = 0.279396772 terabyte
Hmm, valt nog steeds allemaal wel mee
AFTER THOUGHT: chinese karakters... maken die de opslag nou efficiënter of minder efficient logisch gezien zou ik zeggen efficiënter (het is alsof je de taal zelf zipped) maar intuïtief zou ik zeggen minder efficient Dat zijn multibyte karakters, minder efficiënt dus. Als het goed is neemt 1 Chinees karakter 3 bytes in beslag.
Maar je hebt ook minder karakters dus, 1 chinees karakter kan 1 woord zijn, wat dus misschien met onze tekens 2-10 bytes in beslag zou nemen (ook al zijn er ook genoeg chinese woorden van tal van karakters... maar mijn kennis van chinees is zwaar beperkt).
Van die hack op dat devforum vorige week zijn ook de wachtwoorden gepubliceerd.
De meest voorkomende vind je hier:
https://gist.github.com/1508676
Top 5:
('123456789', 235039)
('12345678', 212761)
('11111111', 76348)
('dearbook', 46053)
('00000000', 34953)
De meest voorkomende vind je hier:
https://gist.github.com/1508676
Top 5:
('123456789', 235039)
('12345678', 212761)
('11111111', 76348)
('dearbook', 46053)
('00000000', 34953)
Op nr. 17 staat "1qaz2wsx" welke 3672 keer voorkomt. Vreemd wachtwoord wat toch vaak voorkomt en dan kijk je es naar je toetsenbord... ah vandaar
Ik snap eerder nr. 18 niet.. "xiazhili". Wat is dat nou voor een wachtwoord wat zo hoog scoort??
Wie weet een of ander scheldwoord in het chinees? Scheldwoorden doen het vaak goed als paswoord
http://lmgtfy.com/?q=xiazhili
Vreemd dat ze de wachtwoorden pas sinds 2009 versleuteld opslaan. Zeker voor zo'n groot forum lijkt me beveiliging prioriteit numero uno. Hoe groter, hoe aantrekkelijker om te hacken.
Laf ook dat ze het hebben gepubliceerd. Ik snap niet wat daar het doel van is
Vreemd dat ze de wachtwoorden pas sinds 2009 versleuteld opslaan. Zeker voor zo'n groot forum lijkt me beveiliging prioriteit numero uno. Hoe groter, hoe aantrekkelijker om te hacken.
Laf ook dat ze het hebben gepubliceerd. Ik snap niet wat daar het doel van is
[Reactie gewijzigd door Tarabass op dinsdag 27 december 2011 20:39]
Je beseft dat google helemaal niks verklaard ? Het is een naam... dus? En toch door 3649 mensen gebruikt... apart
? Het is een naam... dus? En toch door 3649 mensen gebruikt... apart naam van hun zoon/vader/opa/broer/beroemd persoon ? Je wil niet weten hoeveel mensen de naam of geboortedatum van dochterlief of vrouwlief gebruiken als wachtwoord.Je beseft dat google helemaal niks verklaard
Op dat devforum blijkbaar minder dan 777 mensen @namen (naja, klopt ni helemaal natuurlijk, maar je begrijpt wat ik bedoel). En blijkbaar is het ook geen veel voorkomende naam (twee naam databanken gechecked) en het is dus ook geen zwaar bekend persoon volgens google... dus nope...
@namen (naja, klopt ni helemaal natuurlijk, maar je begrijpt wat ik bedoel). En blijkbaar is het ook geen veel voorkomende naam (twee naam databanken gechecked) en het is dus ook geen zwaar bekend persoon volgens google... dus nope...[Reactie gewijzigd door David Mulder op woensdag 28 december 2011 10:54]
Sterker nog... Veel gebruikers gebruiken gewoon hun eigen naam als wachtwoord.
Maar inderdaad... Vooral de naam van dochter of vrouw wordt héél vaak gebruikt.
Maar inderdaad... Vooral de naam van dochter of vrouw wordt héél vaak gebruikt.
[Reactie gewijzigd door kimborntobewild op woensdag 28 december 2011 11:20]
1qaz2wsx Is allesbehalve een vreemd wachtwoord... Kijk maar eens naar je toetsenbord . Het valt in dezelfde categorie als 123456789.
. Het valt in dezelfde categorie als 123456789.
40 miljoen is nie zo gek veel gezien het feit dat er 1,339 miljard chinezen rondhuppelen.
Stel je voor 10 kinderen per gezin en dan over 100 jaar... ben blij dat er een limiet aan zit
[Reactie gewijzigd door A87 op dinsdag 27 december 2011 20:28]
Limiet is een groot woord. Je kan nog altijd meerdere kinderen hebben, maar het kost je letterlijk een jaarloon of meer. Tegenwoordig voor vele Chinese een 2 jaar loon.
Nadeel is dat ook kinderen geboren worden welke nooit geregistreerd worden, om geen boete te krijgen, maar voor het systeem bestaan deze niet. Geen gezondheidszorg, enz.
Nadeel is dat ook kinderen geboren worden welke nooit geregistreerd worden, om geen boete te krijgen, maar voor het systeem bestaan deze niet. Geen gezondheidszorg, enz.
Maar wat moet je dan als overheid? Een extra land erbij veroveren of als wereldmaatschappij er een extra planeet bij aantrekken en inrichten speciaal voor chinezen?
We hebben trouwens al wel een planeet op voorraad genaamd "Kepler" misschien dat we daar de eerste miljard proefchinezen naar toe kunnen sturen?
We hebben trouwens al wel een planeet op voorraad genaamd "Kepler" misschien dat we daar de eerste miljard proefchinezen naar toe kunnen sturen?
[Reactie gewijzigd door Fjerpje op woensdag 28 december 2011 00:00]
die limiet geld alleen in de stad, op het platteland van China zijn meer kinderen per gezin nog altijd toegestaan.Stel je voor 10 kinderen per gezin en dan over 100 jaar... ben blij dat er een limiet aan zit
1,346 miljard.40 miljoen is nie zo gek veel gezien het feit dat er 1,339 miljard chinezen rondhuppelen.
[Reactie gewijzigd door kimborntobewild op woensdag 28 december 2011 11:33]
Schandalig dat het kan hoop dat het niet misbruikt word door de hackers.
40 mijoen + 50 miljoen al eerder gestolen gegevens (vast ook alle email adressen)
Die gaan ze dus vol spammen met mails elke dag/week/maand hoeveel zullen er daarvan op een aanbieding in gaan precies ja kassa...
40 mijoen + 50 miljoen al eerder gestolen gegevens (vast ook alle email adressen)
Die gaan ze dus vol spammen met mails elke dag/week/maand hoeveel zullen er daarvan op een aanbieding in gaan precies ja kassa...
Natuurlijk gaat het misbruikt worden... Wat denk je dan?
(ontopic) De link in het artikel wijst naar een Engelstalig stuk van een chinese site.
Je hoeft dus geen Chinees te kunnen.
Je hoeft dus geen Chinees te kunnen.
Op dit item kan niet meer gereageerd worden.
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Apple Microsoft Sony Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
