Hacker steelt wachtwoorden 338.000 accounts carrièresite
Carrièresite Nobiles, waar onder meer Career Event en Masterbeurs onder vallen, heeft de accounts van alle gebruikers gereset omdat een hacker een deel van de accountgegevens heeft gepubliceerd. De wachtwoorden waren niet versleuteld.
Nobiles heeft alle gebruikers via een e-mail op de hoogte gesteld van de hack, vertelt directeur Marlous van Grieken tegen Tweakers.net. "De wachtwoorden waren niet versleuteld, we waren net in het proces om dat te gaan doen." De hacker heeft op Pastebin de gegevens van 900 leden gepubliceerd. In de lijst staan geen gebruikersnamen en in veel gevallen ook geen e-mailadressen en wachtwoorden. Het is daarom onduidelijk hoeveel van de 338.000 gebruikers echt getroffen is.
Als gebruikers opnieuw willen inloggen, moeten ze een nieuw wachtwoord aanmaken. Dat nieuwe wachtwoord wordt volgens Van Grieken wel versleuteld opgeslagen. "Daar zijn we gelijk mee begonnen, want dit is natuurlijk heel vervelend voor ons." Nobiles werd donderdag op de hoogte gesteld van de hack, waarover Webwereld vrijdag publiceerde. De kraak was volgens de hacker mogelijk door gebrekkige beveiliging bij hoster WebdesQ.
Nobiles is een carrièreplatform, waarvan onder meer evenementen als Masterbeurs deel uitmaken. Studenten kunnen de sites gebruiken om informatie te vinden over het zoeken naar een baan. De database bevat velden voor onder meer het adres, telefoonnummer en enkele e-mailadressen. In veel gevallen zijn echter niet alle velden ingevuld; wel zijn bijna alle adressen ingevuld in de dump van de 900 accounts op Pastebin.
De carrièresite is het zoveelste bedrijf binnen korte tijd waarvan bekend wordt dat hackers binnendrongen en data stalen. In de afgelopen week werden onder meer hacks bekend bij biermerk Bavaria, babywinkel Baby Dump en Microsoft Store India, waarbij in alle gevallen gebruikersgegevens werden gestolen. Vorige week werd duidelijk dat telecombedrijf KPN is gehackt, waarbij hackers toegang gehad zouden hebben tot gegevens waaruit blijkt wat KPN-klanten op het internet doen.
Reacties (77)
Het ergste is dat dit niet eens meer schokkend is, bijna normaal tegenwoordig...
Prima als je dingen hackt, maar meld het aan de eigenaar en niet de data verkopen...
Prima als je dingen hackt, maar meld het aan de eigenaar en niet de data verkopen...
Ik heb deze berichten inmiddels wel vaak genoeg gelezen. Bijna iedere dag staat er wel een soort gelijk verhaal op de frontpage. Meestal klik ik ze niet eens meer aan omdat het toch weer hetzelfde verhaal is. Het is natuurlijk wel erg triest dat dit geen nieuws meer is maar dat het eigenlijk normaal geworden is.
Tsja, er staat ook iedere dag smartphonenieuws op de FP 
Het is maar net waar je interesses liggen, het blijft nieuws.
OT:
Nobiles bestaat sinds 1999, misschien was het toen nog niet gebruikelijk om wachtwoorden te versleutelen, maar toch zeker wel een best practice?
In ruim 12 jaar heb je toch een reputatie opgebouwd, en je verwacht van zo'n grote site dat ze toch minstens jaarlijks hun eigen beveiliging bekijken?
Het is maar net waar je interesses liggen, het blijft nieuws.
OT:
Nobiles bestaat sinds 1999, misschien was het toen nog niet gebruikelijk om wachtwoorden te versleutelen, maar toch zeker wel een best practice?
In ruim 12 jaar heb je toch een reputatie opgebouwd, en je verwacht van zo'n grote site dat ze toch minstens jaarlijks hun eigen beveiliging bekijken?
Ja, als ik van een website mijn wachtwoord toegemailt krijg dan stuur ik meteen een email naar de beheerder. Er zijn zelfs hele forum systemen die alles unencrypted opslaan.
Probeer maar eens een business case te maken om de zaak veilig te krijgen. De melding " we gingen het net beveiligen" is natuurlijk ook geen ene klap waard maar de business case is nu ineens wel rond. Lang leve spreadsheet management zonder visie.
OffTopic:
En toch reageer je hier wel weer, heel apart....
@PilatuS:Ik heb deze berichten inmiddels wel vaak genoeg gelezen. Bijna iedere dag staat er wel een soort gelijk verhaal op de frontpage. Meestal klik ik ze niet eens meer aan omdat het toch weer hetzelfde verhaal is. Het is natuurlijk wel erg triest dat dit geen nieuws meer is maar dat het eigenlijk normaal geworden is.
En toch reageer je hier wel weer, heel apart....
[Reactie gewijzigd door HoeZoWie op zaterdag 18 februari 2012 11:06]
Het is vooral jammer dat we er geen conclusies aan verbinden omdat we vaak zelf belang hebben bij internet.
Tegenwoordig? Dit is altijd al zo geweest, alleen nu wordt het topje van de ijsberg in de media gepubliceerd.
Hopelijk doen ze aangifte en weet de politie deze crimineel op te sporen, ik vrees echter het ergste. Dat je een site hackt en samen probeert om dit op te lossen ok, dat je een site hackt, data steelt en dit publiceert omdat je dat met je puisterige kop leuk vindt is niet ok. Hij benadeelt nu mensen die niets aan dit feit kunnen doen, of het hadden kunnen weten.
Welke crimineel? De beheerder van Nobiles?
In sommige gevallen is het goed dat er mensen zijn die dit soort hacks uitvoeren, zeker als er zo onzorgvuldig met de gegevens wordt omgegaan.
Das inderdaad ff kut voor die 900 mensen waarvan de gegevens nu online staan, maar die andere 337.100 worden nu eindelijk wel goed beveiligd.
En dan ga je een klopjacht starten naar deze hacker?
Wie weet heeft een andere hacker al een paar jaar geleden toegang gehad tot de gegevens en deze doorverkocht?
Zolang het niet in de media komt doen sommige bedrijven helemaal niets.
In sommige gevallen is het goed dat er mensen zijn die dit soort hacks uitvoeren, zeker als er zo onzorgvuldig met de gegevens wordt omgegaan.
Das inderdaad ff kut voor die 900 mensen waarvan de gegevens nu online staan, maar die andere 337.100 worden nu eindelijk wel goed beveiligd.
En dan ga je een klopjacht starten naar deze hacker?
Wie weet heeft een andere hacker al een paar jaar geleden toegang gehad tot de gegevens en deze doorverkocht?
Zolang het niet in de media komt doen sommige bedrijven helemaal niets.
De vraag is of de eigenaar van zo'n site daar dan wat aan gaat doen. Digitale schandpaal vind ik een betere oplossing zolang er nog geen wet is die afdwingt dat websites niet zo slordig met data van klanten mogen omgaan.
"De wachtwoorden waren niet versleuteld, we waren net in het proces om dat te gaan doen''
Dat klinkt niet heel geloofwaardig in mijn ogen.
Dat klinkt niet heel geloofwaardig in mijn ogen.
Nou ik vindt het dus wel geloofwaardig, alleen het feit dat het nu pas gebeurd.. In het jaar 2012, dat vindt ik zorgwekkend..
Ik vind dat het verboden moet worden om wachtwoorden niet versleuteld op te slaan. Bij betrouwbare sites gebruik ik (tegen alle adviezen in) altijd hetzelfde wachtwoord. Zolang het (goed) versleuteld is opgeslagen zou dat weinig kwaad moeten kunnen. Door dit soort pruts acties word ik genaaid.
Ik heb Nobiles jaren niet gebruik en nu ook de prutsmail gekregen (een aantal dagen na de hack, en een dag nadat Nobiles is geïnformeerd).
Ter info: de mail tekst
Beste thomas,
Nobiles Media is slachtoffer geworden van een hacker. Jouw gegevens zijn hierbij niet gelekt, maar helaas van 900 anderen wel. Uit voorzorg hebben we van iedereen zijn wachtwoord gereset in onze database. Je kunt dus met je huidige wachtwoord niet meer inloggen op één van de Nobiles websites.
Via de volgende link: www.nobiles.nl/?id=XXX&hash=XXX kun je een nieuw wachtwoord aanmaken.
Als je het wachtwoord voor Nobiles ook gebruikte op andere plekken (bijvoorbeeld Facebook, Hyves, Marktplaats etc.), dan adviseren wij je om dit ook te wijzigen.
Wij betreuren het ten zeerste dat dit gebeurd is en bieden onze welgemeende excuses aan voor het ongemak.
Vriendelijke groeten,
Marlous van Grieken
Directeur Nobiles Media
Ik heb Nobiles jaren niet gebruik en nu ook de prutsmail gekregen (een aantal dagen na de hack, en een dag nadat Nobiles is geïnformeerd).
Ter info: de mail tekst
Beste thomas,
Nobiles Media is slachtoffer geworden van een hacker. Jouw gegevens zijn hierbij niet gelekt, maar helaas van 900 anderen wel. Uit voorzorg hebben we van iedereen zijn wachtwoord gereset in onze database. Je kunt dus met je huidige wachtwoord niet meer inloggen op één van de Nobiles websites.
Via de volgende link: www.nobiles.nl/?id=XXX&hash=XXX kun je een nieuw wachtwoord aanmaken.
Als je het wachtwoord voor Nobiles ook gebruikte op andere plekken (bijvoorbeeld Facebook, Hyves, Marktplaats etc.), dan adviseren wij je om dit ook te wijzigen.
Wij betreuren het ten zeerste dat dit gebeurd is en bieden onze welgemeende excuses aan voor het ongemak.
Vriendelijke groeten,
Marlous van Grieken
Directeur Nobiles Media
Flauwe opmerking hoor, maar die link geeft zelf al aan dat er nog steeds een gigantisch lek zit. Begin maar eens met het invullen van een ander nummer voor de parameter 'ID' en ga een berg gegevens harvesten.Via de volgende link: www.nobiles.nl/?id=XXX&hash=XXX kun je een nieuw wachtwoord aanmaken.
Ik heb het even getest, en zo werkt het niet.
Het eerste id is een pagina ID (die had ik dus best kunnen laten staan; 336). De hash is 32 tekens (combi cijfers en letters) lang, dus het harvesten zal niet heel snel gaan.
32^36 is namelijk erg veel
Het eerste id is een pagina ID (die had ik dus best kunnen laten staan; 336). De hash is 32 tekens (combi cijfers en letters) lang, dus het harvesten zal niet heel snel gaan.
32^36 is namelijk erg veel
Als het een md5 hash is, heb je 't over 16^32
OT: Beheerders met onversleutelde wachtwoorden zouden natuurlijk een pak slaag moeten krijgen.
Maar een tip voor beheerders die nog steeds een enkele md5-implementatie hebben: Wij zaten met een tabel met enkele md5 hashes (zoals t.net ook nog in 2011), maar hebben nu iets als
md5('Salt_6#%!'.md5($pw)), dat valt backwards compatible te implementeren (md5($pw) stond al in de db) en is bijna (niet helemaal) net zo veilig als een salt-per-user op basis van gebruikersgegevens (die een hacker doorgaans ook in bezit heeft)...
Vooruit, nog een tip: zet 1 seconde wachttijd bij een mislukte loginpoging tegen brute-force-attacks op accounts. Nog een tip als je bang bent dat je site vatbaar is voor injection: leer toch eens PDO om met je db te communiceren, zo ingewikkeld is dat echt niet... Kun je veilig dingen als getOne("SELECT x FROM y WHERE z=:z",array(':z'=>$_POST['z'])) doen..
OT: Beheerders met onversleutelde wachtwoorden zouden natuurlijk een pak slaag moeten krijgen.
Maar een tip voor beheerders die nog steeds een enkele md5-implementatie hebben: Wij zaten met een tabel met enkele md5 hashes (zoals t.net ook nog in 2011), maar hebben nu iets als
md5('Salt_6#%!'.md5($pw)), dat valt backwards compatible te implementeren (md5($pw) stond al in de db) en is bijna (niet helemaal) net zo veilig als een salt-per-user op basis van gebruikersgegevens (die een hacker doorgaans ook in bezit heeft)...
Vooruit, nog een tip: zet 1 seconde wachttijd bij een mislukte loginpoging tegen brute-force-attacks op accounts. Nog een tip als je bang bent dat je site vatbaar is voor injection: leer toch eens PDO om met je db te communiceren, zo ingewikkeld is dat echt niet... Kun je veilig dingen als getOne("SELECT x FROM y WHERE z=:z",array(':z'=>$_POST['z'])) doen..
[Reactie gewijzigd door AugmentoR op zaterdag 18 februari 2012 00:04]
Nog een tip: De eerste goede login reken je alsnog fout.
Dit doet onze Outlook server via OWA. Serieus. Rete-irritante bug, maar eigenlijk een extra beveiliging
Dit doet onze Outlook server via OWA. Serieus. Rete-irritante bug, maar eigenlijk een extra beveiliging
Dat is inderdaad doordacht - bedankt voor deze waardevolle tip. 
[Reactie gewijzigd door HoeZoWie op zaterdag 18 februari 2012 11:08]
Versleutelde wachtwoorden vertragen alleen het proces. Je zult alsnog je wachtwoord moeten veranderen.
De versleuteling wordt gebruikt om de hackers lang genoeg te vertragen zodat alle gebruikers ondertussen nieuwe wachtwoorden hebben.
Het probleem met versleutelde wachtwoorden is dat bedrijven of gebruikers denken dat ze wel veilig zitten, dit is dus absoluut niet zo.
Zie het als een kluis, die je op de een of andere manier in je eigen werkplaats heb staan. Gegeven dat ik lang genoeg tijd en de goede tools heb, zal ik altijd de kluis open kunnen krijgen.
Verschil tussen een kluis en versleutelde wachtwoorden, is dat de wachtwoorden niet vergaan, maar de inhoud van de kluis wel kapot kan.
De versleuteling wordt gebruikt om de hackers lang genoeg te vertragen zodat alle gebruikers ondertussen nieuwe wachtwoorden hebben.
Het probleem met versleutelde wachtwoorden is dat bedrijven of gebruikers denken dat ze wel veilig zitten, dit is dus absoluut niet zo.
Zie het als een kluis, die je op de een of andere manier in je eigen werkplaats heb staan. Gegeven dat ik lang genoeg tijd en de goede tools heb, zal ik altijd de kluis open kunnen krijgen.
Verschil tussen een kluis en versleutelde wachtwoorden, is dat de wachtwoorden niet vergaan, maar de inhoud van de kluis wel kapot kan.
Hoezo niet. Het zal vaak genoeg gebeurd zijn vroeger. Toen hacken niet zo hot was, was die noodzaak er ook veel minder. Het zal veelal ook zo'n dingetje zijn geweest van, dat moeten we een keer doen.
Nu hacken dagelijks in het nieuws is kan ik me voorstellen dat je zo'n proces toch een keer op gaat pakken.
Nu hacken dagelijks in het nieuws is kan ik me voorstellen dat je zo'n proces toch een keer op gaat pakken.
Dat bedrijven nog steeds hun wachtwoorden onversleuteld opslaan na zoveel ophef het laatste jaar is toch onbegrijpelijk.
Nobiles heeft onder haar leden de volgende email uitgestuurd:
Nobiles Media is slachtoffer geworden van een hacker. Jouw gegevens zijn hierbij niet gelekt, maar helaas van 900 anderen wel. Uit voorzorg hebben we van iedereen zijn wachtwoord gereset in onze database.
[Reactie gewijzigd door Rex op vrijdag 17 februari 2012 17:11]
Zou je die mail naar mij kunnen forwarden (of een screenshot sturen) [ arnoud et tweakers punt net ]? Dan kan ik dat toevoegen aan het artikel. Voor de duidelijkheid: de directeur bevestigde telefonisch dat de gegevens kloppen, er bij hen ingebroken is en dat de hacker de database heeft kunnen leeghalen. Hij claimt zelf dat hij dat gedaan heeft. Dat is voor ons voldoende reden om aan te nemen dat het inderdaad zo is (zeker omdat het niet is tegengesproken 
)
Edit: dank, heb het mailtje inmiddels van meerdere mensen geforward gekregen. Ik heb de tekst in een pdf en een plaatje aan het artikel toegevoegd
)Edit: dank, heb het mailtje inmiddels van meerdere mensen geforward gekregen. Ik heb de tekst in een pdf en een plaatje aan het artikel toegevoegd
[Reactie gewijzigd door arnoudwokke op vrijdag 17 februari 2012 17:27]
Ik heb die e-mail ook gekregen.
In ieder geval speelt Nobiles hier open kaart en heeft heel snel eigenlijk deze mail uitgestuurd.
Het is vooral lastig omdat dit toch een site is die vrij veel persoonlijke informatie bevat, het is immers een vacature-site die probeert je te helpen bij het vinden van een baan. En dan hebben ze nogal wat van je nodig. Gelukkig geen financiele info, maar als ze die bij Baby-dump opvissen en combineren is identity-theft opeens wel heel erg makkelijk.
In ieder geval speelt Nobiles hier open kaart en heeft heel snel eigenlijk deze mail uitgestuurd.
Het is vooral lastig omdat dit toch een site is die vrij veel persoonlijke informatie bevat, het is immers een vacature-site die probeert je te helpen bij het vinden van een baan. En dan hebben ze nogal wat van je nodig. Gelukkig geen financiele info, maar als ze die bij Baby-dump opvissen en combineren is identity-theft opeens wel heel erg makkelijk.
Het is een tricky mail. ze zeggen 'de rest is niet gelekt', ze bedoelen 'de rest is ook gestolen, nog niet gepubliceerd, maar wel in handen van de hacker'.
Ik denk dat ze bedoelen gelekt door de hacker en niet gelekt door Nobiles Media
*Zucht*
Zoveelste website waarbij de ontwikkelaar 'vergeten' is om de wachtwoorden te salten en daarna te hashen.
Zoveelste website waarbij de ontwikkelaar 'vergeten' is om de wachtwoorden te salten en daarna te hashen.
Versleutelen is niet hetzelfde als hashen. Hashen is obfuscatie.
Ik schreef dan ook "salten" en niet zoals je vermoedelijk dacht "versleutelen".Versleutelen is niet hetzelfde als hashen. Hashen is obfuscatie.
http://en.wikipedia.org/wiki/Salt_%28cryptography%29
Door een "salt" toe te voegen aan hetgeen je hasht, maak je je tabel met gehashte wachtwoorden minder kwetsbaar voor een aanval op basis van rainbowtables. De "salt" maakt dan dat je voor iedere waarde voor die salt opnieuw een rainbowtable op moet gaan bouwen. Ben je vervolgens echt goed bezig, dan houdt je voor ieder wachtwoord een aparte "salt" bij en dan levert een rainbowtable aanval geen voordeel meer op tegenover simpelere bruteforce aanvallen.
Eerst salten en daarna hashen is niet per definitie veel effectiever. Als jij hash(wachtwoord+salt) toepast, dan is het voor een hacker niet lastig om met een rainbowtable te achterhalen hoe de vork in de steel zit. Het patroon van wachtwoord+salt zal snel genoeg opvallen (de salt kan je niet geheim houden), waardoor ook het originele wachtwoord zo te achterhalen is. In dit geval gaat ook niet op dat je voor elke salt een aparte rainbowtable zou moeten gebruiken.
Veiliger is bijvoorbeeld hash(hash(wachtwoord)+salt) o.i.d., aangezien je dan minder snel het originele wachtwoord alsnog kan achterhalen met een rainbowtable.
Dit voorbeeld is overigens slechts ter illustratie, er zijn nog veel meer technieken om de hash nog meer te versterken.
Veiliger is bijvoorbeeld hash(hash(wachtwoord)+salt) o.i.d., aangezien je dan minder snel het originele wachtwoord alsnog kan achterhalen met een rainbowtable.
Dit voorbeeld is overigens slechts ter illustratie, er zijn nog veel meer technieken om de hash nog meer te versterken.
[Reactie gewijzigd door Ram0n op vrijdag 17 februari 2012 18:46]
De rainbow table moet worden opgebouwd aan de hand van een salt, dat is altijd al effectiever.
En waarom zou je salt niet geheim te houden zijn? Als je salt niet in je database staat en ze hebben enkel je database gegevens dan hebben ze simpelweg je salt niet. Volgens mij zijn er zat opensource CMS'en etc die ook simpelweg de salt ergens in een tekstbestandje zetten en het aanmaken bij de installatie van het CMS zelf.
En waarom zou je salt niet geheim te houden zijn? Als je salt niet in je database staat en ze hebben enkel je database gegevens dan hebben ze simpelweg je salt niet. Volgens mij zijn er zat opensource CMS'en etc die ook simpelweg de salt ergens in een tekstbestandje zetten en het aanmaken bij de installatie van het CMS zelf.
Die rainbow table hoeft dus niet altijd opnieuw opgebouwd te worden, in ieder geval niet als je simpelweg eerst de salt aan het wachtwoord toevoegt en dan hashed. In dat geval kan je altijd een standaard rainbow table gebruiken, want wat daar uit komt is simpelweg wachtwoord+salt. Als je dan de salt weet is het direct duidelijk wat het wachtwoord was.
Dit is een veelgemaakte denkfout rondom het gebruik van salts.
De veiligheid van je hash met salt mag verder natuurlijk nooit afhangen van de geheimhouding van de salt.
Dit is een veelgemaakte denkfout rondom het gebruik van salts.
De veiligheid van je hash met salt mag verder natuurlijk nooit afhangen van de geheimhouding van de salt.
"Daar zijn we gelijk mee begonnen, want dit is natuurlijk heel vervelend voor ons."
en je gebruikers ook lijkt me ?
en je gebruikers ook lijkt me ?
Dat vind ik nog het vervelendste van dit soort lekken. Men lijkt niet alleen veiligheidsrisico's te laag in te schatten (waardoor grote fouten zoals plaintext wachtwoorden opslaan gebeuren) maar men ziet ook niet dat dit de gebruikers ernstig kan duperen, méér dan het bedrijf zelf. Één zo'n prutssite waar je je e-mailadres en wachtwoord voor dat e-mailadres op hebt staan (omdat je hetzelfde wachtwoord vaker gebruikt) en je kan echt grote persoonlijke schade ondervinden. e-mail gehackt -> veel accounts die via je e-mail te benaderen zijn ook gehackt en je komt er zelf niet meer in. Tuurlijk is het niet handig om hetzelfde wachtwoord te gebruiken, maar veel mensen doen dit nu en daar moet een database-beheerder rekening mee houden zodra hij wachtwoorden op gaat slaan.
Die uitspraak straalt arrogantie uit, "och wat is het erg voor ons" terwijl ze de fout zelf maken en de gebruikers de enige zijn die nu eventueel gevolgen ondervinden van identiteitsfraude.
Die uitspraak straalt arrogantie uit, "och wat is het erg voor ons" terwijl ze de fout zelf maken en de gebruikers de enige zijn die nu eventueel gevolgen ondervinden van identiteitsfraude.
[Reactie gewijzigd door bwerg op vrijdag 17 februari 2012 19:35]
Inderdaad. Het zou daarom ook best bij wet verboden mogen worden om wachtwoorden ongehashed op te slaan, wat mij betreft.
"De wachtwoorden waren niet versleuteld, we waren net in het proces om dat te gaan doen." Wat was nou de regel over achteraf beveiligen?
en de tegenstelling met:
"Daar zijn we gelijk mee begonnen, want dit is natuurlijk heel vervelend voor ons."
en de tegenstelling met:
"Daar zijn we gelijk mee begonnen, want dit is natuurlijk heel vervelend voor ons."
De wachtwoorden waren niet versleuteld. - zucht
Ach ja, we lezen genoeg berichten dat de meeste versleuteling ook zo terug te rekenen is met hash tabellen.......
de juiste term is rainbow tables
Het is echt onbegrijpelijk dat er nog steeds websites zijn die wachtwoorden van hun klanten onversleuteld opslaan. Er zijn in elke courante programmeertaal toch meerdere methodes om wachtwoorden te versleutelen. Je hoeft er ook geen raketgeleerde voor te zijn. Voor encryptie met een salt moet je al iets meer doen, maar ook dat is eigenlijk nog een peulenschil voor de programmeurs.
Zijn programmeurs zo vergeetachtig (of gewoon dom), of voeren ze enkel de opdracht uit die hun onwetende opdrachtgever heeft bedacht?
edit: velen waren mij voor met dit commentaar...
Zijn programmeurs zo vergeetachtig (of gewoon dom), of voeren ze enkel de opdracht uit die hun onwetende opdrachtgever heeft bedacht?
edit: velen waren mij voor met dit commentaar...
[Reactie gewijzigd door roland83 op vrijdag 17 februari 2012 17:11]
Wat ik denk dat voor veel van dit soort sites geldt is dat ze natuurlijk al wat ouder zijn. De database-tabel met account-gegevens is een van de oudste onderdelen, daar sleutelt men niet zo snel aan. Aandacht gaat toch al snel naar andere, geld-verdienende, onderdelen.
Ook Tweakers.net, die echt prioriteit geven aan dit soort dingen, heeft bijvoorbeeld pas recent het gebruik van het "gekraakte" MD5 uitgefaseerd:
plan: Analyse: zwakke wachtwoorden op Tweakers.net
Het is dus denk ik niet zozeer laakbaarheid van de programmeur, als dat er vroeger veel minder aandacht voor was en dat sindsdien de security van de database op dit vlak niet goed onderhouden is, domweg neit de prioriteit heeft.
Ook Tweakers.net, die echt prioriteit geven aan dit soort dingen, heeft bijvoorbeeld pas recent het gebruik van het "gekraakte" MD5 uitgefaseerd:
plan: Analyse: zwakke wachtwoorden op Tweakers.net
Het is dus denk ik niet zozeer laakbaarheid van de programmeur, als dat er vroeger veel minder aandacht voor was en dat sindsdien de security van de database op dit vlak niet goed onderhouden is, domweg neit de prioriteit heeft.
Wat valt er aan te sleutelen? Dit zijn dingen die prima volledig automatisch te testen zijn (je hebt de plain tekst passwords toch al).
Je geeft elke gebruiker een unieke salt, bereken een digest over de salt plus plain text password (dat heb je al) en sla beiden op in database. Vervolgens past je 'wachtwoord controle" stukje aan.
Een beetje programmeur kan dit zeker binnen 1 dag opleveren, getest, gedocumenteerd (!) en wel.
Zie ook b.v.: http://phpsec.org/articles/2005/password-hashing.html
Je geeft elke gebruiker een unieke salt, bereken een digest over de salt plus plain text password (dat heb je al) en sla beiden op in database. Vervolgens past je 'wachtwoord controle" stukje aan.
Een beetje programmeur kan dit zeker binnen 1 dag opleveren, getest, gedocumenteerd (!) en wel.
Zie ook b.v.: http://phpsec.org/articles/2005/password-hashing.html
Gegeven websites die hun password validatie allemaal netjes gestructureerd hebben, en er niet op meerdere plekken dezelfde controle gedaan wordt.
Ik vind het niet een excuus, maar om nu te zeggen dat een beetje programmeur dat zeker binnen 1 dag kan opleveren, is ook weer erg kort door de bocht. Ja, bij websites die echt goed in elkaar zitten wel. Nu werken helaas genoeg websites en systemen op brakke structuren, en zijn de achterliggende bedrijven allang blij dat het allemaal draait. Een verandering in user authentication kan dan toch behoorlijk ingrijpend zijn.
Ik vind het niet een excuus, maar om nu te zeggen dat een beetje programmeur dat zeker binnen 1 dag kan opleveren, is ook weer erg kort door de bocht. Ja, bij websites die echt goed in elkaar zitten wel. Nu werken helaas genoeg websites en systemen op brakke structuren, en zijn de achterliggende bedrijven allang blij dat het allemaal draait. Een verandering in user authentication kan dan toch behoorlijk ingrijpend zijn.
Als dezelfde code op meerdere plaatsen zit is dit gelijk een mooie gelegenheid om dat in 1x op te ruimen. En uiteraard kan je dat met de nodige tools zo "zien" (find, grep, enz). Blijf er bij dat dit en niet meer dan een dag mag kosten (tenzij het een enorme bende spaghetti code is, maar dan heb je meerdere problemen) en dat het prima volledig automatisch te testen is.
Het andere probleem wat hier op zeker aanwezig is, de SQL injectie, kost wat meer tijd, maar dat is ook prima op te lossen in een week.
Maar goed, kost natuurlijk geld, en het vinden van een beetje programmeur is ook niet makkelijk (blijkt aan hoe vaak dit soort dingen op duiken).
Ben soms wel blij dat ik (freelance) Perl programmeur ben, en dus zelden tot nooit dit soort rommel hoef op te ruimen (Perl wordt niet zo druk meer gebruikt op het web, wel jammer, maar goed).
Het andere probleem wat hier op zeker aanwezig is, de SQL injectie, kost wat meer tijd, maar dat is ook prima op te lossen in een week.
Maar goed, kost natuurlijk geld, en het vinden van een beetje programmeur is ook niet makkelijk (blijkt aan hoe vaak dit soort dingen op duiken).
Ben soms wel blij dat ik (freelance) Perl programmeur ben, en dus zelden tot nooit dit soort rommel hoef op te ruimen (Perl wordt niet zo druk meer gebruikt op het web, wel jammer, maar goed).
Jammer dat ze niet versleuteld op hebben geslagen, dat is wel heel slecht. Ik vraag me nu dus zelf ook af welk wachtwoord ik daar heb gehad, oftewel welke nu niet meer veilig is. (En nee, ik ga niet al mijn wachtwoorden wijzigen, alle belangrijkste zijn toch wachtwoorden die ik niet bij Nobiles heb gebruikt).
Wel in iedergeval positief dat ik al mail van ze had dat het gebeurd was, dus ze hebben wel de getroffenen snel geinformeerd.
Wel in iedergeval positief dat ik al mail van ze had dat het gebeurd was, dus ze hebben wel de getroffenen snel geinformeerd.
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
