Privégegevens 63.000 NL Energie-klanten liggen op straat

De inloggegevens van meer dan 63.000 klanten van de Nederlandse Energie Maatschappij liggen op straat, waaronder die van 'NL Energie-gezicht' Maurice de Hond. De privacygevoelige en onversleutelde data stond te kijk in een open directory.

Een anonieme bron tipte Tweakers.net dat hij op de website van de Nederlandse Energie Maatschappij, oftewel NL Energie, met grote eenvoud een open directory aantrof. Deze map bleek gevuld met xls-bestanden waarin de gebruikersnamen, wachtwoorden en e-mailadressen van NL Energie-klanten in plain text zijn te vinden. Het gaat in totaal om meer dan zestigduizend klanten. Onder andere het account van 'NL Energie-gezicht' Maurice de Hond blijkt in de lijsten voor te komen.

Met de data kan in de meeste gevallen worden ingelogd op de Mijn Energie-beheerpagina, zo blijkt uit een kleine steekproef. Hierbij zijn diverse persoonlijke gegevens opvraagbaar, waaronder het energieverbruik, openstaande rekeningen en adresgegevens van een NL Energie-klant.

De xls-bestanden die in de publiek toegankelijke directory stonden, lijken voor backupdoeleinden te worden gebruikt. Toch worden alle basisregels voor het veiligstellen van persoonlijke gegevens geschonden. Niet alleen worden de backupbestanden op een publiek toegankelijke server weggeschreven, de data was bovendien onversleuteld opgeslagen. Bovendien kan het lekken van wachtwoorden gevolgen hebben voor NL Energie-klanten, omdat veel internetgebruikers dezelfde wachtwoorden op verschillende sites gebruiken.

Het energiebedrijf, dat in het afgelopen jaar onder de slogan 'Ik zeg doen' klanten probeerde te strikken, zou echter alle getroffen klanten moeten aanschrijven om direct een ander wachtwoord te kiezen. Het is immers niet duidelijk of de klantgegevens al door anderen zijn gevonden en eventueel misbruikt. Daarnaast moet de beveiliging van NL Energie-site grondig onder de loep worden genomen.

De Nederlandse Energie Maatschappij heeft inmiddels, na door Tweakers.net te zijn geïnformeerd, de open directory verwijderd. Ook moeten NL Energie-klanten die de dienst Mijn Energie gebruiken een nieuw wachtwoord kiezen, zo meldt directeur Harold Swinkels aan Tweakers.net. Zij worden daarover schriftelijk geïnformeerd.

De NL Energie-directeur zegt dat er een 'intern onderzoek' naar het lek is gestart. Het gaat volgens Swinkels vermoedelijk om 'een menselijke fout van een programmeur'. NL Energie zegt verder vooralsnog geen verdachte transacties te hebben gezien.

Maurice de Hond heeft telefonisch aan Tweakers.net bevestigd dat de door de tipgever verzamelde verbruiksgegevens over De Hond correct zijn. De Hond noemt dergelijke fouten bij bedrijven 'slordig en betreurenswaardig'.

Reacties (190)

[racrooy]

Toen ik (half jaar geleden) zelf op de website van de NEM een account aanmaakte kreeg ik een mail met mijn username en wachtwoord erin.

Ik heb toen direct aan de bel getrokken en een mail gestuurd. Het duurde een week of twee weken als ik het me goed herinner, maar toen belde iemand mij op om me te bedanken etc.
Ze zouden het gaan fixen, bla bla bla.

Twee maanden geleden moest ik weer op hun website zijn, als test mijn wachtwoord eens gewijzigd en GVD nog steeds plaintext reply met mijn wacthwoord.

En nu dit... nou ik heb ze gewaarschuwd en ze hebben me gebeld dus iemand heeft het actief genegeerd.

[Woy]

Het hoeft niet direct een probleem te zijn dat ze je wachtwoord clear-text mailen op het moment dat je wachtwoord wijzigt. Immers zegt dat niks over het feit of het wachtwoord clear-text opgeslagen is. Immer op het moment van wijzigen is het wachtwoord natuurlijk gewoon beschikbaar.

Op het moment dat je bij een password retrieval weer je originele wachtwoord krijgt, dan moeten natuurlijk wel meteen alle alarmbellen afgaan.

[durian]

Het hoeft niet direct een probleem te zijn dat ze je wachtwoord clear-text mailen op het moment dat je wachtwoord wijzigt. Immers zegt dat niks over het feit of het wachtwoord clear-text opgeslagen is. Immer op het moment van wijzigen is het wachtwoord natuurlijk gewoon beschikbaar.

Als ze het kunnen mailen is het plain-text password over het internet naar de NEM verstuurd. Ook is het dan door allerlei mailservers gegaan. Dat wil je ook allemaal niet. Het lijkt me beter om het password meteen in de webapplicatie te versleutelen, en dan pas te versturen.

[racrooy]

Precies,

Als ze een challenge response mechanisme pakken bijvoorbeeld, hebben ze aan de hash en de salt genoeg.

Nu is het voor mij geen probleem, ik heb voor mezelf een variatie op het challenge response principe gepakt om voor elke applicatie/website een uniek paswoord te maken, dat ook nog eens zeker aan alle 'strong password' eisen voldoet.

[Reactie gewijzigd door racrooy op 23 juli 2024 00:43]

[Radhe]

Het lijkt me beter om het password meteen in de webapplicatie te versleutelen, en dan pas te versturen.

Het spijt me dat ik die logica niet kan volgen? Voordat je't in de database (of een ander opslagmedium) stopt, moet het versleuteld worden. Voor het versturen lijkt het me niet nuttig het te versleutelen

Enfin.. De reden dat ze het vaak plain text versturen is dat het voor de gebruiker een bevestiging geeft dat hun wachtwoord is veranderd. Maar het is inderdaad discutabel of ze het wachtwoord op zich mee moeten sturen. Een bevestiging dat je't hebt veranderd is uiteraard al voldoende.

Als je wachtwoord daarentegen altijd via het systeem wordt gegenereerd, zul je dat toch op de 1 of andere manier moeten communiceren. Via reguliere post zit je dan vaak al een paar dagen later. Via e-mail is dat directer. Is het compleet veilig? Nee...

En wat te denken van de wachtwoorden op zich inderdaad. Mensen zijn gewoontedieren, oftewel vaak dezelfde wachtwoorden.

Wat overigens wel netjes zou zijn, is dat je voor het invoeren op de beveiligde omgeving zit.

[BeosBeing]

[...]
Enfin.. De reden dat ze het vaak plain text versturen is dat het voor de gebruiker een bevestiging geeft dat hun wachtwoord is veranderd. Maar het is inderdaad discutabel of ze het wachtwoord op zich mee moeten sturen. Een bevestiging dat je't hebt veranderd is uiteraard al voldoende.

Eens

Als je wachtwoord daarentegen altijd via het systeem wordt gegenereerd, zul je dat toch op de 1 of andere manier moeten communiceren. Via reguliere post zit je dan vaak al een paar dagen later. Via e-mail is dat directer. Is het compleet veilig? Nee...

Daarom moet het gegenereerde en per e-mail/telefoon doorgegeven wachtwoord bij het eerste inloggen geweizigd worden, in het geval van de telefoon vaak terwijl de klant nog aan de telefoon hangt met de helpdesk.

En wat te denken van de wachtwoorden op zich inderdaad. Mensen zijn gewoontedieren, oftewel vaak dezelfde wachtwoorden.

Wat is erger, steeds hetzelfde wachtwoord gebruiken of steeds bij iedere keer inloggen opnieuw een password moeten aanvragen.
Sinds ze bij een bepaalde site de 'strong password' eisen verscherpten, werken mijn normale passwords (zonder hoofdletters) niet meer en moet ik bij iedere keer inloggen opnieuw een password verzinnen en instellen (niet via telefoon). Dat is lekker veilig. [/quote]

Automatisch gegenereerde passwords zijn ook vrijwel onmogelijk om te memoriseren, zeker als je er meerdere hebt.

[Paul van Druten]

Schande ik heb al een klacht ingestuurd aan [e-mail] (college bescherming persoonsggevens) met het verzoek deze prutsers een vette boete te geven!

Ik roep jullie op dat ook te doen!

[PhilipsFan]

"Menselijke fout van een programmeur". Ja natuurlijk. Het is de fout van een laaggeplaatste. Niet van de hoge piefjes die een goed beveiligings-, omgevingen- en beheerbeleid hebben uitgedacht, geimplementeerd en getest.

En als ze geen programmeur kunnen laten opdraaien dan heeft "de schoonmaker het gedaan".

[ajakkes]

Nee, het is de schuld van degene die de server met het internet heeft verbonden.

Maar, inderdaad, er is bij het management niet genoeg aandacht besteed aan beveiliging.

Als aan de programmeur wordt gevraagd om in zo kort mogelijke tijd de boel online te zetten en daarbij geen aandacht wordt besteed aan de mogelijkheid van beveiligingsproblemen is dit niet de fout van de programmeur.

Mits het hoofd van deze afdeling wel heeft aangegeven dat er meer prioriteit gegeven zou moeten worden aan de beveiliging van deze gegevens.

[Makkelijk]

Het punt is dat niemand een programmeur zal vragen om geen aandacht te besteden aan de mogelijkheid van beveiligingsproblemen. Het is 'common sense' dat iets wat je bouwt geen beveiligingsproblemen heeft. Het is ook 'common sense' dat een timmerman een constructie timmert die niet instort. Om deze reden is in dit geval de programmeur wél verwijtbaar. Als een collega van mij dit zou doen, zou ik hem daar zeker op aanspreken en niet de directeur die niet heeft gezegd dat hij geen onbeveiligde wachtwoorden op een onbeveiligde plek op de server mag zetten.

[i-chat]

Ik wil nog een stap verder gaan, iemand die dit implementeerd dient op een zwarte lijst gezet te worden PUNT. fouten kun je maken, dit soort gedoe natuurlijk niet

en dan heb ik het vooral over het stukje onversleutelde wachtwoorden.

uiteindelijk kan ik er maar 1 ding op zeggen, management -10 voor goedkoop beleid
programmeur -80 en direct ontslag omdat ie zich blijkbaar bemoeit met dingen waar ie geen verstand van heeft. -5 voor de gebruikers/klanten die zo stom is om de NEM serieus te nemen. en die andere -5 voor alle collega's en andere personen die er nooit bij stil hebben gestaan dat dit iets raars en mogelijk zelfs onwettigs is ....

[ajakkes]

Hier ben ik het niet met je eens. Hoe stom de fouten zijn die gemaakt zijn zou je over kunnen discussiëren.

Maar je moet in mijn ogen altijd de beveiliging controleren. Je kan beveiliging van een site niet af laten hangen van 1 programmeur.

Deze fouten dien je te testen. Als je in je ontwerp specificeert dat je geen plain-text wachtwoorden op wil slaan zal de programmeur deze ook niet opslaan.

Degene die de opdracht geeft tot het bouwen van de website zal zich terdege moeten laten informeren hoe hij de gegevens van zijn klanten kan/ en moet beveiligen. Hoe hij controleert of laat controleren dat de gegevens van zijn klanten daadwerkelijk beveiligd zijn.

En dan heb ik het niet over de plaatselijke webshop die zijn zelfgemaakte kerstkaarten verkoopt.

Maar wel over een site waar meer dan 1% van de huishoudens klant is.

[Woy]

Dat is natuurlijk alleen waar tot op bepaalde hoogte. Bepaalde fouten ( zoals het clear-text opslaan ) zou je als programmeur niet moeten maken. Maar het is ook afhankelijk van hoe de scope van het project opgesteld is.

Voor een bank zul je bijvoorbeeld op een andere manier tegen de security aankijken dan voor een site zoals tweakers. Daarbij is ook de vraag welke eisen er aan een systeem gesteld worden. Ik kan me zomaar indenken dat een van de eisen is dat support medewerkers de wachtwoorden moeten kunnen zien. Dan zit de grootste fout al in de requirements, want dat zou nooit een requirement mogen zijn. ( Al is het dan nog steeds een fout dat het clear-text ergens staat )

[BeosBeing]

Supportmedewerkers moeten het wachtwoord kunnen resetten/opnieuw instellen, meer niet.
Password mailen is al riskant. Mail is zowiezo ook meestal niet versleuteld, dus te onderscheppen.

[Reactie gewijzigd door BeosBeing op 23 juli 2024 00:43]

[Treenaks]

Wat als de programmeur het verteld heeft, maar het uit kosten/"het gebeurt toch nooit"/etc.-overwegingen toch nooit iets mee gedaan is?

[Verwijderd]

Als je een timmerman een opdracht geeft zonder ook maar een vorm van een ontwerp zal die iets anders afleveren dan dat jij in gedachte had.
Daarom moet je ook bij ICT projecten een ontwerp maken en daar hoort het puntje beveiliging gewoon in.

Alle opmerkingen hierboven van onversleutelde wachtwoorden, wellicht is dat wel by design... (vreemde keuze, er zijn veiligere opties om ook bij verloren wachtwoord een veilige reset password procedure te starten, maar dan nog).

Sowieso is het niet de fout van de programmeur, daar hij alleen heeft geïmplementeerd wat er is ontworpen. Het is wel de fout van de ontwerper (kan dezelfde persoon zijn natuurlijk), die heeft een ontwerp neergezet waarin dit soort beveliigingslekken mogelijk zijn.

[humbug]

Het is niet de taak van een programmeur om de website te beveiligen. Als een programmeur de data wegschrijft naar een directory op de server, dat documenteert en zijn leidinggevende het goedkeurt is zijn werk gedaan. Hij gaat niet over de beveiling van de server en of de directory nu open of dicht staat. Sterker een programmeur raakt als het even kan een productieserver niet eens aan. Ieder zijn taak en uiteindelijk is de hoogste baas gewoon verantwoordelijk. Hij had blijkbaar anderen moeten inhuren of naar de adviezen moeten luisteren.

Maar naar beneden schopen is een stuk makkelijker.

[BeosBeing]

Tja, waarom nu net die open directory en niet een andere share om gegevens naar weg te schrijven. Als de programmeur niet beter weet als 'die map/share moet je daarvoor gebruiken, dan kunnen we er allemaal bij als het nodig is' en niet weet dat die map dus open staat voor andere doeleinden, dan valt hem niets te verwijten.

En vaak weet men wel dat niet alles qua structuur. helemaal in orde is, maar wordt daar aan gewerkt maar moet de boel ondertussen wel blijven draaien.

[BeosBeing]

Als de programmeur iets gemaakt heeft voor intern gebruik (dat dus niet bedoeld is voor toegang vanaf buiten) en een ander maakt vervolgens een export van de gegevens (want dat is handig als naslag/backup/...), een derde plaatst die vervolgens op een share (waar intern iedereen bij kan, want dat is handig) en die share hangt 'toevallig' ook aan de website, dan heb je het zitten.

Wie is de verantwoordelijke? Degene die de export gemaakt heeft, degene die de export op de share geplaatst heeft of degene die de share aan de website heeft gekoppelt?
De 1e persoon heeft de gegevens niet versleuteld (want was niet nodig, de bestanden waren immers beperkt toegankelijk), de tweede heeft de gegevens niet beveiligd (rechten ingesteld) want die wist niet dat de share aan de website hing, of de derde die nooit verwacht had dat dit soort gegevens op deze share geplaatst zou worden, er waren immers andere shares intern.

Allen zijn deels verantwoordelijk omdat ze geen van allen hebben nagedacht over de vertrouwelijkheid van de gegevens en/of onvoldoende op de hoogte waren van de structuur van de shares, wie kan waar bij. Dat is dan weer vooral de schuld van het management dat dit er bij betrokkenen niet genoeg heeft ingehamert en dat niet heeft gedocumenteerd wie waarbij kan op de shares.

[MRTNbos]

Een beetje offtopic, maar om in te gaan op je puntje timmerman:

Je hebt een constructie die niet instort, een contructie, en een sterke contructie.

Iedereen kan een paar spijkers of schroeven in hout rammen. Maar als je bv mooi verdekte zwaluwstaarten wil hebben, wat veel mooier en steviger is, dan hangt daar zeker een prijskaartje aan vast.

Zo ook met deze beveiligings kwestie: Ik denk dat 95% van de nederlandse internetgebruikers nooit bij deze wachtwoorden zal kunnen komen. (Waarschijnlijk myself included). (spijkers & schroeven)

Als ik dan de reacties hier zo lees heb je daarnaast de ervaren hobbyist die met enige moeite deze (blijkbaar relatief eenvoudige) fout kan achterhalen. Als laatste dan nog de doorgewinterde "vakman" die dit op z'n sloffen doet.

Maar zoals met alles: wat is de prijs/kwaliteit verhouding die de opdrachtgever opgeeft?! Ik denk dat het probleem in de meeste gevallen daar ligt. Iedereen vind goeie degelijke techniek/producten geweldig tot het moment dat het prijskaartje bekend wordt. Dan is veel minder vaak ook opeens genoeg...

[Verwijderd]

Het is altijd een fout van de programmeur of systeembeheerder, zij hebben namelijk het probleem gecreëerd, niet de hoge pief die alleen weet waar de aan/uit knop zit.

Het feit dat er geen protocollen zijn mbt beveiliging, of dat deze niet (goed) worden gevolgd is wat anders, en hier zijn de hoge heren wel voor verantwoordelijk. Al is het voor hen wel erg lastig om zelf te controleren (zie eerst alinea voor reden).

OnTopic: Het is al erg dat er persoonsgevens open en bloot beschikbaar zijn, maar dat het (waarschijnlijk) een 1-op-1 export van de database is, zonder versleutelde wachtwoorden is wel heel erg. Zelfs een stagiair weet dat je altijd wachtwoorden moet versleutelen...

Het feit dat ze MijnEnergie over SSL laten lopen is dan wel weer een pluspuntje


Update: Niemand kan op dit moment inloggen vanwege "onderhoud" :

Mededeling

Op dit moment is Mijn Energie wegens onderhoudswerkzaamheden tijdelijk niet beschikbaar. Wij verwachten dat u morgen weer gebruik kunt maken van Mijn Energie. Onze excuses voor het ongemak.

Met vriendelijke groet,
De Nederlandse Energie Maatschappij

[kKaltUu]

Het is de fout van de projectmanager, die het functioneel/technisch ontwerp goedkeurt.

[jbtbnl]

Als ik even mag raden: er was geen projectmanager

[mpkossen]

Het is zelf de verantwoordelijkheid van de programmeur om te zeggen "Ho, wacht eens even, plain text wachtwoorden opslaan, dat doen we niet." Men hoeft niet te verwachten dat een directie-lid daar ook maar iets vanaf weet.

Ik vind dit echt een groot falen van de ontwikkelaar(s). Hopelijk gaat de NEM naar een ander, die wel verstand van zaken heeft. Want dit soort fouten, oei, zijn toch wel heel erg van het gehalte

[dmystic]

eigenlijk helemaal niet, je zou het wel moeten doen, maar vaak luisteren mensen niet eens naar je, en als je dan zegt, ik doe het niet, zoeken ze wel een andere die het wel op die manier doet,

als bv management zegt dat er een excel bestandje gemaakt moet worden voor een bepaalde afdeling die het nodig heeft(of die vinden dat ze het nodig hebben) en geen verstand hebben van versleutelde verbindingen, de infrastructuur is bagger en het bedrijf heeft geen zin om te investeren daarin, kan je als programmeur kiezen tussen opzouten en het gewoon doen.

nou zou de verstandigste keuze natuurlijk zijn om gewoon weg te gaan, maar je moet toch eten op de plank krijgen, dus kan me wel voorstellen dat dat niet gebeurt.

[aikebah]

Naar mijn mening zou iedere web-programmeur minimaal moeten weigeren om moedwillig zaken in een site op te nemen die ingaan tegen de OWASP Top Ten.

En volgens mij http://www.owasp.org/inde...ory:OWASP_Top_Ten_Project hebben we hier toch minimaal 3 van de 10 te pakken in dit gevalletje:

# A6: Security Misconfiguration
# A7: Insecure Cryptographic Storage
# A8: Failure to Restrict URL Access

ergo: wel degelijk een menselijke fout van de programmeur (hetzij door zich te laten dwingen moedwillig Top-Ten risico's te introduceren danwel door het onbedoeld inbouwen van deze risico's)

[BeosBeing]

Niet zijnde een web-programmeur heb ik nog nooit van dat lijstje gehoord hoor.
Als ik nu de opdracht krijg om een website (extern of intern) te maken, zou ik me van die lijst niets aantrekken. Ik zou al blij zijn als ik het allemaal werkend kreeg. Desondanks zou ik er voor zorgen dat de toegankelijke gegevens van de bedrijfsinterne gescheiden zouden zijn, al is in Windows Server een verkeerd geplaatst vinkje snel gemaakt (waarna de rechten voor alle submappen worden aangepast).

[Svardskampe]

eigenlijk helemaal niet, je zou het wel moeten doen, maar vaak luisteren mensen niet eens naar je, en als je dan zegt, ik doe het niet, zoeken ze wel een andere die het wel op die manier doet,

als bv management zegt dat er een excel bestandje gemaakt moet worden voor een bepaalde afdeling die het nodig heeft(of die vinden dat ze het nodig hebben) en geen verstand hebben van versleutelde verbindingen, de infrastructuur is bagger en het bedrijf heeft geen zin om te investeren daarin, kan je als programmeur kiezen tussen opzouten en het gewoon doen.

nou zou de verstandigste keuze natuurlijk zijn om gewoon weg te gaan, maar je moet toch eten op de plank krijgen, dus kan me wel voorstellen dat dat niet gebeurt.

^ Dit

Is veelal de gang van zaken, niet het scenario van de onbekwame programmeur die velen hier aanhalen.

[MRTNbos]

Helemaal mee eens!

Ik denk dat het scenario wat je hier beschrijft in de meeste gevallen het probleem is, en dat het maar sporadisch voorkomt dat de "vakman" onbekwaam is.

[cariolive23]

hebben uitgedacht

Daar doe je een aanname!

1) Het mag niks kosten
2) Het moet gisteren klaar zijn
3) kwaliteit? Wat is dat?

En zie daar het gemiddelde IT-project... Helaas maar waar en ik maak er nog deel van uit ook.

[Shadowhawk00]

Natuurlijk want ICT is een kostenpost de niets opleverd dus moet het zo goedkoop mogelijk. Testen nah kost te veel, beveiliging nou ja omdat het moet dan maar zolang het maar niet te veel kost.
Echt erg maar zo gaat dat.

[TGEN]

Uit welingelichte bronnen heb ik vernomen dat Maurice de Hond de klusjesman van deze zaak verdenkt .

[Woy]

Maar het blijft een fout van een programmeur, want het had nooit op deze manier in elkaar gezet mogen worden.

Wachtwoorden mag je nooit en te nimmer clear-text opslaan. Het is een basis beginsel van beveiliging dat je wachtwoorden voor een dergelijk systeem altijd hashed ( met salt ) moet opslaan, zodat de hash nooit te herleiden is naar het wachtwoord.

Ik zou mijn persoonlijke gegevens dan ook nooit meer aan de NEM toevertrouwen, aangezien ze blijkbaar geen flauw benul hebben over hoe ze met vertrouwelijke gegevens om moeten gaan.

Helaas gebeurt dat tegenwoordig nog steeds bij te veel bedrijven. Het feit dat deze gegevens op een publiek toegankelijke plek stonden vind ik persoonlijk nog een stuk minder erg dan dat de basis blijkbaar al totaal verkeerd is.

Een lek in de gegevens is helaas altijd mogelijk ( al moet het natuurlijk zo veel mogelijk voorkomen worden ), maar het is dan belangrijk om te zorgen dat die gegevens zo min mogelijk waarde hebben.

[Verwijderd]

Ook lekker makkelijk om altijd de hooggeplaatste de aansprakelijkheid toe te schuiven... De gesignaleerde problemen lijken wel degelijk op het niveau van de programmeur te liggen, en hebben niets van doen met de directeuren.

[i-chat]

op het moment dat je als werkgever NIET toetst of jouw personeel bekwaam bezig is doe je iets grondig fout (management les 1 2 3 4 5 en 6 )

[ajakkes]

Ja, en dat is nou precies waar die hooggeplaatsten hun salaris voor krijgen. Zorgen dat het beleid goed is. Het personeel bekwaam. En de hiërarchie goed in elkaar steekt.

Het wil niet zeggen dat het management de fout heeft gemaakt. Maar de schuld bij de programmeur leggen is ook fout.

[flabber]

En weer verbaasd het me....

De gegevens van 8+ miljoen nederlanders zijn opvraagbaar bij de ING en men roept "Houden zo! Goeie feature!".
Vervolgens zijn (waren) de gegevens van 60+ duizend NEM klanten opvraagbaar en er wordt bijna opgeroepen om programmeurs te gaan lynchen.

Uiteraard zit er verschil tussen beide lekken (want dat zijn het mijns inzeins allebei!), maar het verschil in reactie is toch verbazingwekkend!

[Haan]

Uiteraard zit er verschil tussen beide lekken (want dat zijn het mijns inzeins allebei!), maar het verschil in reactie is toch verbazingwekkend!

Dat is nogal een understatement! Bij de ING ging het om een naam en rekeningnummer, waar je in principe vrij weinig mee kan.
Hier gaat het om accountgegevens, inclusief wachtwoord in plaintext waarmee je dus gewoon in kon loggen! Dan hebben we het nog niet eens over het feit dat deze in een Excel bestand stonden (erg ongebruikelijk) én in open directory. Dus nee, het verschil in reactie is niet zo verbazingwekkend

[Verwijderd]

bij de ING was werden naam en rekeningnummer gezien om fouten zoals overschrijven naar een verkeerde persoon terug te dringen.
maar ik heb er geen moeite mee als iemand mijn rekeningnummer weet zeker niet als ie wat geld over heeft

in tegenstelling tot het probleem bij de NEM waar iedereen kan zien welke rekeningen ik open heb staan en hoeveel ik jaarlijks betaal en als zou dat het enige zijn maar nee ook mijn wachtwoord kan men achterhalen en aangezien ik niet voor elke account een ander wachtwoord aan maak kan men dus op meerdere plaatsen met mijn wachtwoord inloggen....

ik vind het belangrijk dat ik het geld naar de goede persoon overmaak
ik vind het ook belangrijk dat men niet bij mijn geld kan......

[Basguijt]

Wat betreft de ING is dit zeker een lek of mss wel een intern probleempje. Mijn email adres was uniek en alleen bekend bij de ING, was alleen aan de ING bekend gemaakt.....
Helaas wordt deze inbox nog steeds gebruik door iedereen die er graag mijn inlog gegevens wil hebben.
Tja, geen ING meer voor mij

[Giesber]

Enerzijds is hier al gezegd dat het soort data bij ING minder kritisch was: er stond bijvoorbeeld al geen wachtwoord in plain text in.

Anders is ook dat het bij ING geen lek was, maar een bewuste keuze om de naam en rekeningnummer publiek toegankelijk te maken. Hoewel het misschien een design fout is van de gegevens bloot te stellen, zat er niks mis met de beveiliging van de gegevens. Het is niet zo dat er een lijst van namen en rekeningnummers beschikbaar was op de servers van ING, dus hun beveiliging zit blijkbaar beter in elkaar dan bij NL Energie (en maar goed ook).

[Verwijderd]

Kan De Nederlandse Energiemaatschappij hier eigen ook boete voor krijgen?

[Tijger]

Mischien, de Wet Bescherming Persoonsgegevens zou dan vermoedelijk het aangewezen vehikel zijn maar ik weet niet zeker of die ook in boetes voorziet bij nalatigheid.

[watercoolertje]

Hoewel nalatigheid inderdaad ook een kwestie is! Volgens mij mogen wachtwoorden enkel geëncrypteerd opgeslaan, dat dat niet gebeurt is hier mee bewezen en staat dus los van dit bestand...

Denk dat ze daar toch wel voor op hun vingers getikt KUNNEN worden Wil niet zeggen dat het gebeurd natuurlijk!

[Reactie gewijzigd door watercoolertje op 23 juli 2024 00:43]

[mpkossen]

Gok dat het wel gebeurt, gezien de omvang van het probleem. Ik hoop eigenlijk dat hier iemand met verstand van wet- en regelgeving dit leest en even een beargumenteerd oordeel kan geven of dit nou wel of geen overtreding is.

[Verwijderd]

Is daar niet het College Bescherming Persoonsgegevens voor? De wet verplicht het beveiligen van persoonsgegevens. Het CBP ziet er daarom op toe dat deze wet wordt nageleefd. Boetes bij het niet naleven van de regels kunnen oplopen tot € 4500,-. Afgezien van deze boete loopt het nalatige bedrijf ook nog het risico aansprakelijk gesteld te worden voor de schade.
(Artikel 66)

Zie ook de Wet Bescherming Persoonsgegevens
http://wetten.overheid.nl/BWBR0011468/

En het CBP
http://www.cbpweb.nl/Pages/ind_cbp.aspx

Edit:
Quote van de privacy disclaimer van de NEM:

De Nederlandse Energie Maatschappij acht de bescherming van de persoonlijke levensfeer van haar klanten en bezoekers van haar website van essentieel belang. Persoonlijke gegevens van klanten en bezoekers worden dan ook met de grootst mogelijke zorgvuldigheid behandeld en beveiligd.

De Nederlandse Energie Maatschappij houdt zich aan de eisen die de Wet Bescherming Persoonsgegevens stelt. In overeenstemming met de Wet Bescherming Persoonsgegevens is de verwerking aangemeld bij de Toezichthouder, het College Bescherming Persoonsgegevens, gevestigd te Den Haag.

Als ze zich dus niet aan de eisen die de wet stelt houden, moet je bij het CBP zijn.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:43]

[Verwijderd]

Okay dan!!!
Lekker handig :-S

Ik vraag me af waarom ze dit soort beginnersfouten uberhaupt maken?

Als je het hebt over een CMS van een scholier die een eerste PHP opdracht maakt., okay.
Van die denkfouten dat je in de url ziet staan user=xxx&ingelogged=ok

Dat kan ik begrijpen.

maar dit is een redelijk groot bedrijf dat toch wel enkele duizende euro's te besteden heeft.
Dan vraag ik me af waarom??

[Verwijderd]

Jammer genoeg is ICT land tegenwoordig gevuld met amatuertjes die mee willen snoepen van de ICT taart. Het is dan diegene met snelste babbel of het laagste bod welke opdrachten binnenhaalt en niet diegene met de meeste vakbekwaamheid. Bedrijven en de overheid zouden de regels van de bouw sector moeten toepassen op ICT. Eerst laten zien wat je trackrecord is en een paar refferenties geven en dan pas wordt je toegelaten.

ik vindt het trouwens goed dat dit soort dingen in de media komen. Misschien dat bedrijven eens beter gaan nadenken over hun beleid. Zullen we maar zeggen (of hopen): "Zelfs een ezel stoot zich niet 2x aan dezelfde steen".

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:43]

[Verwijderd]

Ik las laatst een aardige sig van een ict-er: Bedrijven klagen dat goed ictpersoneel zo duur is. Ze hebben waarschijnlijk geen idee over de kosten van slecht ict-personeel.

[Verwijderd]

"If you pay peanuts, you will get monkeys." is ook zo'n gerelateerde uitspraak..

Vaak inderdaad voor een dubbeltje op de eerste rang willen zitten met een paar stagiaires (opm.: hier zitten echt, echt wel erg goede tussen.. maar 't merendeel moet echt nog wel het e.e.a. leren).

Heb het ook wel bij wetenschappelijk onderzoek gezien hoor. Onderzoeken van een paar jaar lang met pakweg een miljoen aan subsidie, maar 15 mille voor de hard- en software waar het onderzoek op draait is niet bespreekbaar. Dan liever nog even een extra promovendus.. en een heleboel gedonder verderop in de pijplijn omdat op verschillende locaties verouderde systemen worden gebruikt. (hoe 386/486 systemen op een locatie zoals bijv. scholen worden ingezet met bijv. de muziekleraar als beheerder, dat idee.. maar wel real-time complexe dingen willen meten...om nog maar te zwijgen over het hebben van een uniforme en gestandaardiseerde meetomgeving).

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:43]

[Radhe]

15 mille... Ja, voor hardware is die prijscategorie nog wel relevant.

Als je op programmeergebied een paar goede profs los laat, dan kom je nog maar net kijken. Begin dan maar ergens op 60 mille, dan begin je in de richting te komen.

Ik heb op een ICT afdeling gezeten met vnl. freelancers. Dan heb je het bij twee maanden al snel over een paar ton!

[BeosBeing]

Vaak inderdaad voor een dubbeltje op de eerste rang willen zitten met een paar stagiaires (opm.: hier zitten echt, echt wel erg goede tussen.. maar 't merendeel moet echt nog wel het e.e.a. leren).

Daarom moeten stagairs ook begeleiding krijgen. Helaas heeft men daar ook vaak geen budget voor. Of men laat ze aanmodderen of (zoals in de zorg een paar jaar geleden) men neemt geen stagairs aan omdat men onvoldoende personeel heeft om ze te begeleiden. En in het laatste geval men heeft onvoldoende personeel omdat ze niet voldoende gekwalificeerd personeel kan verkrijgen. Lijkt me dat die twee elkaar dan mooi in stand houden. Gevolg is dus dat studenten geen stage kunnen lopen en/of kunnen afstuderen, en daardoor is er dus onvoldoende gekwalificeerd personee.

[Verwijderd]

Een van de grootste problemen is denk ik het feit dat er geen jarenlang traject of substantiele investering vastzit aan het zelfstandig ICT-er zijn; iedereen kan in principe morgen beginnen.
Dit zorgt ervoor dat de prijzen structureel omlaag zullen convergeren.
Ook de verdergaande centralisatie van clouddiensten en de invloed van open source
zullen ervoor zorgen dat de boterham per stuk minder dik besmeerd is en zal blijven.

[Verwijderd]

Dat is niet helemaal correct vindt ik. Er zijn manieren om onderscheid te maken tussen iemand die gisteren is begonnen en iemand die wel verstand van zaken heeft. Dat kan men aan de hand van certificaten, opleidingen en referenties. Er zijn wel degelijk manieren om onderscheid te maken maar dat doet men niet omdat men onwetend is of omdat men het onnodig acht.

[dotnetpower]

Opleiding / certificaten en referenties (als je menselijke referenties bedoeld, van de verkeerde mensen) zijn totaal geen goede referentiekader.

Wat men nodig heeft is iemand binnen het bedrijf met verstand van zaken die door dat soort "opleukpapiertjes" heenprikt en kijkt naar wat iemand daadwerkelijk kan... ik kom vaak genoeg HBO'ers tegen die gewoon goed kunnen leren, maar niks in de praktijk kunnen toepassen omdat ze of totaal geen interesse hebben en het maar zijn gaan doen omdat er zat werk is in de ICT (de 9 tot 5 mentaliteit personeel) of omdat ze nooit een goede begeleiding hebben gehad van mensen met de juiste kennis en ervaring.

Wat je eigenlijk zou moeten hebben is dat men tijdens hun opleiding of vlak na, binnen een (erkend door een door het vakgebied aangestelde organisatie) bedrijf komt te werken waarop je op een juiste manier word opgeleid en begeleid.

Ben momenteel ook als ZZP'er ook met een opdracht bezig voor een semi overheid waarin ik moet samenwerken met een groot bedrijf (helaas achteraf toen alles fout was gegaan) waarvan men zegt dat het met een behoorlijk aantal "specialisten" het afgelopen half jaar heeft aangewerkt, maar ondertussen heeft de uiteindelijke klant betaald voor een product wat technisch niks voorstelt en die veel te laat is opgeleverd en ook nog is 1 grote puinzooi is waaraan geen vorm van standaarden is toegepast (en ja de specificaties zijn gewoon duidelijk en niet veranderd).

En als je dan de meest simpele dingen vraagt om aan te passen (b.v. iets aanroepen na een bepaalde Ajax request) dan kennen ze die concepten niet eens en iets anders dan tables / inline styling en inline Javascript komt er ook niet uit (en dan gek vinden dat het toch wel wat traag werkt bij de klant op IE ).

[Verwijderd]

of het beste van beide werelden:
de bedragen van de ICT en de nauwkeurigheid van de bouwsector, dan kan er echt weer wat moois gemaakt worden
Kijk maar eens wat de prijzen van de aanbestedingen door de wegvallende bouwvolumes in de utiliteit doentegenwoordig

[RobIII]

maar dit is een redelijk groot bedrijf dat toch wel enkele duizende euro's te besteden heeft.

Bij dat soort projecten gaat 't over tonnen of meer

Desalniettemin kansloos; een fout maken kan iedereen gebeuren maar dit is toch wel een major fuckup... En wachtwoorden überhaupt in plaintext hebben geeft al weer aan hoe knullig zo'n project in elkaar steekt

[Reactie gewijzigd door RobIII op 23 juli 2024 00:43]

[tMb]

Geen Md5 hash dus. Waarschijnlijk kon je met een druk op de knop je wachtwoord laten mailen naar je e-mail adres als je het vergeten was

[Verwijderd]

So what als ze wel gehashed waren?

Dit is (was) een collectie van 63000 paswoorden en de meeste mensen gebruiken waardeloze paswoorden.

De hash is niet terug te leiden naar het paswoord, maar het is een kleine moeite een dictionary attack te doen, hashes te vergelijken en oogsten maar!

Edit: een salt maakt het uiteraard moeilijker, maar met 63000 zeer simpele paswoorden ga je hoe dan ook resultaat boeken.

Het belangrijkst is natuurlijk dat een bestand als dit nooi binnen handbereik komt van het publiek.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:43]

[esak]

Als je serverside een "salt" toevoegd aan die hash is een dictionary attack niet meer mogelijk .

[airell]

Attack is niet eens nodig... gooi '598d4c200461b81522a3328565c25f7c' maar eens in Google... Dat is een attack van milliseconden, er zijn genoeg mensen die een simpel wachtwoordje hebben die zo te achterhalen zijn.

http://www.google.com/sea...00461b81522a3328565c25f7c

[plakbandrol]

Ik mag toch aannemen dat elk professioneel bedrijf salt gebruikt bij het coderen van passwords.

-edit- eask was me al voor

[Reactie gewijzigd door plakbandrol op 23 juli 2024 00:43]

[Eegee]

Wachtwoord, niet paswoord.

[BeosBeing]

passeerwoord dan?

[barfieldmv]

Vervolgens moest iemand control-f doen om je wachtwoord in de xls file te pakken en die in een respose mailtje te zetten zeker.

[Verwijderd]

Ik denk dat ze hier met een paar tientjes klaar waren. Klantenbestand beheren in excel, oef.

[BeosBeing]

Tja, men had MsOffice aangeschaft en toen was het budget op.

[DJMaze]

nem.nl headers:

Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET

Waarom zit je zo op PHP te bashen, het kan met elke programmeer taal hoor

[dev10]

Hij basht niet op PHP, maar op beginners die in PHP redelijke triviale fouten maken.

[DJMaze]

Ik bedoel dat zijn verhaal niet objectief is. In elke programmeer taal maken beginners fouten.
PHP wordt meestal aangehaald als het probleem omdat het zo makkelijk is in gebruik en veel OpenSource projecten hiermee zijn uitgerust.

Maar als ik kijk naar closed source code geschreven in C++ of ASP is het niet veel beter.
Ik kan zo nog 10 websites opnoemen waarbij hele SQL queries gewoon in de GET/POST data staan (zoals bam.nl), en die draaien niet op PHP.

Vandaar voelt het bij mij een bash naar PHP omdat het zo'n makkelijk antwoord is, terwijl het probleem veel groter is dan die ene taal.

[Verwijderd]

Dat doet 'ie helemaal niet, Ik stel voor dat je voortaan de reacties wat beter leest, want nu zit je te "bashen" op iets wat niet bestaat.

[Squeezert]

Het is wel erg vaak raak de laatste tijd.

Met in het achterhoofd dat misschien 80% van de internetgebruikers voor alles het zelfde wachtwoord gebruikt, hebben we het hier over een serieus probleem. Bedrijven hebben een zorgplicht als het gaat om het veilig bewaren van persoonsgegevens. Ik heb echter nog nooit gehoord dat in Nederland een bedrijf voor dergelijke nalatigheid is beboet. .

In politiek den Haag moet ook echt eens het kwartje vallen dat er een minister van informatie moet komen. Wat mij betreft al 20 jaar geleden. Het is volstrekt onacceptabel de manier waarop bedrijven omgaan met persoonlijke informatie. Ieder bedrijf zou moeten aantonen aan een bepaalde mate van informatiebeveiliging te doen. 1000 euro voor iedere uitgelekte klant per dag online lijkt me voldoende afschrikwekkend

[koter84]

of mensen gaan eens bedenken dat je niet hetzelfde wachtwoord voor alle diensten moet hebben....
maar in ieder geval 1 voor vertrouwde diensten, en 1 voor niet vertrouwde diensten... en dan misschien nog een voor vertrouwde diensten die high-risk zijn (bijvoorbeeld je mail/facebook/online opslag....) of natuurlijk zo'n password-manager...

( met high risk bedoel ik dan hoog risico indien gekraakt )

[Reactie gewijzigd door koter84 op 23 juli 2024 00:43]

[Ramoncito]

Ben ik nou echt de enige die nimmer een wachtwoord voor een site twee keer gebruikt?

Het is niet echt heel moeilijk om wachtwoorden gescheiden op te slaan op je PC (in een datakluis programmatje) of simpelweg in een schrift (wat ik heb).

Je browser bewaard alle wachtwoorden toch voor je? Je hoeft ze echt niet allemaal te herinneren.. Een schriftje heeft meer voordelen: alsie crashed ben je ze niet kwijt

[ChevyVan79]

Of gewoon een wachtwoord wat simpel (voor jou) te herrineren is en dan plak je de naam van de website ervoor.

[Verwijderd]

Dat dacht ik ook, maar het komt vele malen per week voor dat ik opeens weer moet inloggen omdat ergens in de windows jungle van de browser de boel verdwenen is.

[drijfhout]

Ik vraag me af of je op zo een "Mijn Energiebeheer" pagina ook kunt zien op welke tijdstippen er het meeste stroom wordt verbruikt.
Dat in combinatie met adresgegevens is voor inbrekers natuurlijk ontzettend handig.

Maar goed dat deze lek ondekt is, kan namelijk voor grote problemen zorgen.

Ik zie de nieuwe reclame al voor me :

Man met een bivakmuts en een breekijzer in zijn hand : ik zeg... DOEN!!!

[highmastdon]

Dus jij bent nooit thuis 's nachts?

[drijfhout]

En er wordt zeker nooit ingebroken als mensen in hun bed liggen?

En als mensen naar hun werk gaan zetten ze meestal ook bijna alles uit in huis, dus dat zul je misschien ook nog kunnen zien.

En je zou ook nog uit het verbruik ongeveer kunnen uitlezen of er veel dure apparaten in huis staan.
Bepaalde huizen zullen er echt wel tussenuit springen.

Kortom, gevaarlijk.

[Reactie gewijzigd door drijfhout op 23 juli 2024 00:43]

[Yezpahr]

Hij bedoelde dat de inbrekers dan weten hoe laat die personen naar bed gaan, omdat de meeste mensen hun computer-meuk wèl uitzetten als ze naar bed gaan.

[metallicelmo]

En wat nou als iemand deze gegevens gebruikt om iemand zijn of haar energieplan te wijzigen? Lijkt me nogal lullig maar het kan denk ik wel of niet? Wie is er dan schuldig

[i-chat]

de nem omdat ze nu niet meer aannemelijk kunnen maken dat jij het werkelijk was....