Privégegevens 63.000 NL Energie-klanten liggen op straat

Reacties

« 1 2 3 4 5 6 7 »

Door watercoolertje, maandag 6 december 2010 14:46

Wachtwoord wijzigen? Ik zeg DOEN!

Door Wnoise92, maandag 6 december 2010 14:48

Door highmastdon, maandag 6 december 2010 14:53

Door MisterLBP, maandag 6 december 2010 14:53

Door r100, maandag 6 december 2010 15:08

NEM kiezen? Ik zeg OEN!

Ontopic:
Het gaat hier om een 'menselijke fout' van een programmeur.
Maar ook al zou er geen open directory zijn, dan nog kun je je afvragen waarom al die gegevens in een Excel-bestand worden bewaard. Voor vertrouwelijke gegevens verwacht ik geen onversleuteld huis-tuin- en keuken bestandsformaat.

Door DJMaze, maandag 6 december 2010 15:28

Helemaal mee eens, je bent wel heel erg dom als je dat in Excel opslaat.
Versleuteling op het web blijft discutabel, je moet immers ergens de sleutel opslaan anders kan je het niet decoderen.
Als iemand inlogged op je server via een onveilige SSH dan is de sleutel natuurlijk ook zo gevonden.
De sleutel zou dus nooit op het internet mogen staan.

Door Radhe, maandag 6 december 2010 18:32

Je kunt encryptie op basis van AES Rijndael doen op een email adres, dan is die gemaskeerd.

Een wachtwoord sla je meestal op via MD5 of SHA1, maar dan wel 'salted'; oftewel met een keyword die je ergens op de server hebt opgeslagen met enkele details die alleen bekend zijn binnen het systeem - danwel binnen hetzelfde record, danwel in een andere tabel met referentie en je kunt zelfs het in het formulier - maar gebruik nooit een 'plain' hash. Voordeel van hashes is: je kunt het nooit precies reverse 'enigineeren'. Er zijn immers meerdere varianten die in dezelfde hash kunnen resulteren.

En voor de slimmerikken: Een wachtwoord kun je dan niet opvragen. Nee, je maakt een nieuw wachtwoord en die stuur je op.

Dit is een veelal toegepaste techniek omdat die - je raad het al - de meeste veiligheid bied.

MAAR NOOIT plain text!!! En waarom in hemelsnaam in een XLS bestand???

En: ik tik hier HASH, niet HASJ

Even voor de duidelijkheid

[Reactie gewijzigd door Radhe op maandag 6 december 2010 18:33]

Door dotnetpower, maandag 6 december 2010 22:05

Precies... altijd passwords hashen / salten en over een encrypted lijn sturen of eerst bij de client-side genereren, dat is toch gewoon 1+1 voor een programmeur?

Leuk dat er dan word gesproken over "een menselijke fout van een programmeur", volgens mij duid dit gewoon op incompetentie bij die programmeur en of bij zijn controleurs als die er überhaupt al waren.

En vervolgens ook nog is bij de persoon die niet doorhad dat bij een export van de database alle wachtwoorden gewoon even in plain werden meegeplaatst (en uberhaupt zouden die niet moeten meegenomen worden).

Ik kreeg een paar maanden terug ook een opdracht om een website aan te passen waarbij ik door de rotzooi erachter kwam dat ook hier alle wachtwoorden in plain werden opgeslagen en op tig manieren dit te achterhalen was d.m.v. SQL injection, dan zit je echt met verbazing te kijken als je zoiets aantreft, helaas stonden de naam en of contactgegevens van die "programmeur" nergens in de code

.

Edit:
@Atheistus
Ik weet uit 1e hand waar je op doelt, ik werk namelijk voor ASP'er die als "underdog" in die markt opereert... de bedragen die zij vragen voor low quality websites is echt om te huilen , laat me het zo zeggen.. als makelaar

. Maargoed die hele woningmarkt word gedomineerd door 1 partij die de consument indirect behoorlijk naait op digitaal gebied.

@abei
Nee duh je moet er natuurlijk niet voor zorgen dat als men een script maakt en daar direct die hash die in de input velden plakt en submit (bypas van JS) ie dan kan inloggen ;-).

Echter alleen hashen achteraf biedt niet voldoende beveiliging.. stel dat de gebruiker bijvoorbeeld inlogged over een open WIFI verbinding, dan is het wel handig om het password dus ook niet plain over de lijn te sturen (aftappen), meestal voorkom je dat dus door een SSL verbinding op te zetten, voor gevallen dat je dat niet kan kun je hem beter aan de client side 1maal hashen en hem vervolgens salten bij binnenkomst en zo vergelijken / opslaan dan helemaal plain alles oversturen.

[Reactie gewijzigd door dotnetpower op dinsdag 7 december 2010 14:54]

Door Atheistus, dinsdag 7 december 2010 02:27

Tja, maar er zijn nog steeds bedrijven die hun website door het spreekwoordelijke "neefje" laten bakken. Een tijd geleden heb ik bij een makelaar een enorm lek in hun website aangetoond. Je kon zomaar van elke klant alle gegevens inzien en wijzigen.
Ze schrokken wel, maar omdat die markt in handen is van een een paar zeer slechte webbouwers, werd er niets aan gedaan. En zo knoeien ze verder en komt er af en toe dit soort nieuws.

Door abei, dinsdag 7 december 2010 13:20

Iets met een klok en klepel?

Een password hashen client side maakt het weinig veiliger: effectief heb je dan het password vervangen door de hash. In plaats van dat je het password niet meer in de database kunt achterhalen heb je van iedereen het password gewoon veranderd in de hash.

Door sam.vimes, woensdag 8 december 2010 08:45

[...] je kunt het nooit precies reverse 'enigineeren'. Er zijn immers meerdere varianten die in dezelfde hash kunnen resulteren.

Die meerdere varianten zijn eerder een nadeel: dat maakt de kans groter dat je een geschikt password vindt, ook al is het niet het password dat oorspronkelijk was gekozen. Omdat het oorspronkelijke password niet meer bestaat, maakt het niet uit of de hash berekend is uit het oorspronkelijke password of uit het toevallig gevonden alternatief dat dezelfde hash oplevert.

De reden voor hashing is, dat het extreem moeilijk is om uit een gegeven hash het oorspronkelijke password te reconstrueren. Een hash-functie heeft geen inverse. Je kunt niet door "slim proberen" snel naar het password toe werken, je moet gewoon alle mogelijkheden proberen (brute force) todat je het goede (of een geschikt) wachtwoord hebt gevonden. Tel daarbij op dat het berekenen van een hash-functie vaak een langdurige zaak is (in computertijd); dat maakt het onbegonnen werk om uit gehashte passwords de oorspronkelijke passwords terug te rekenen.

Door Hensz, maandag 6 december 2010 15:36

Lekkere menselijke fout, een onversleuteld bestand zo maar onversleuteld online zetten. Dit soort bestanden hoort van buitenaf keihard en totaal onbereikbaar te zijn.
Dit is nou de zoveelste keer dat een groot bedrijf niet goed op z'n gegevens past.
Ik overweeg inmiddels sterk om bedrijven geen enkele persoonlijke info meer te geven en degenen die mijn info hebben, die terug te vragen, desnoods maar klant-af worden.
De maat is vol!

Door MADG0BLIN, maandag 6 december 2010 15:37

En waar ga je dan je stroom afnemen, je gas, je bankrekening etc?
Er is geen enkel bedrijf dat dat doet zonder die informatie...

Door BeosBeing, dinsdag 7 december 2010 10:20

Zonnepanelen op je dak is al haalbaar, nu nog overdag de energie opslaan voor 's avonds. Koken op gasflessen (doen ze in de meeste landen) of als je (zoals m'n schoonouders) dat te duur vind op hout (is in NL dan weer duur) , zelf een waterput slaan (heb je wel een vergunning nodig van de gemeente, die krijg je niet zomaar meer, moet je geloof ik aantonen dat je bij het waterleidingbedrijf geen aansluiting kunt krijgen) je kunt een heel eind komen.

Ik zeg doen. Het zal ze leren. Ook voor telefoon raad ik prepaid aan.
Alleen is wettelijk bepaald dat je werkgever je salaris MOET overmaken op een bankrekening, dan kan de overheid dat namelijk controleren.

Door appelsaus, maandag 6 december 2010 16:48

Succes ermee, dan mag je al je geld contant gaan bewaren, heel veel kaarsen kopen en buiten onder een brug gaan leven ofzo.

Door Fireshade, maandag 6 december 2010 17:34

NEM kiezen? Ik zeg OEN!

Ja verwarrend he?
NL Energiemaatschappij is niet hetzelfde als NEM.
De NEM moet ondertussen al gek gebeld zijn door de naamkeuze van de Nederlandse Energiemaaschappij.

Door toetie10, maandag 6 december 2010 23:36

De NL Energiemaatschappij is wel de NEM dat is hetzelfde, de NEM is de afkorting oen
;-)

Door Proxy, dinsdag 7 december 2010 00:57

NEM is Nederlandsche Electrolasch Maatschappij.

Door tukkerpaddy, dinsdag 7 december 2010 06:56

Ze presenteerden zich in het verleden anders wel als NEM. Later werd dit, waarschijnlijk omdat NEM al bestaat, NL Energie.

Door baafie, maandag 6 december 2010 20:31

Het gaat hier om een 'menselijke fout' van een programmeur.

Het is dan weer jammer voor de echte programmeurs dat mensen die met excel bestanden en Windows directory sharing werken er met het predikaat 'programmeur' vandoor gaan.

Door daft_dutch, maandag 6 december 2010 22:33

Practiced what preached.

De xls kan een adhok actie zijn geweest. Dat er in die dump unencrypted wachtwoorden in zitten is wanbeleid.

[Reactie gewijzigd door daft_dutch op maandag 6 december 2010 22:33]

Door Vioo, maandag 6 december 2010 16:16

Als het je niets zou doen dan zou je dat niet zeggen.

Door BeosBeing, dinsdag 7 december 2010 09:51

Tja, ik kan nu al niet meer bij m'n pagina's bij NL Energie, Rabobank, Visa en VGZ, wie zou mijn wachtwoorden gewijzigd hebben?

(Gelukkig zit ik niet bij een van die clubs.

)

[Reactie gewijzigd door BeosBeing op dinsdag 7 december 2010 09:51]

Door popolskuprosze, maandag 6 december 2010 14:48

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??

Door RobIII, maandag 6 december 2010 14:52

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 maandag 6 december 2010 14:53]

Door snirpsnirp, maandag 6 december 2010 15:10

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

Door BeosBeing, dinsdag 7 december 2010 13:28

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

Door tMb, maandag 6 december 2010 15:13

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

Door barfieldmv, maandag 6 december 2010 15:29

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

Door Teddy Rukspin, maandag 6 december 2010 16:31

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 Teddy Rukspin op maandag 6 december 2010 16:49]

Door esak, maandag 6 december 2010 16:37

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

Door airell, maandag 6 december 2010 16:38

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

Door plakbandrol, maandag 6 december 2010 16:40

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 maandag 6 december 2010 16:40]

Door Eegee, maandag 6 december 2010 19:51

Wachtwoord, niet paswoord.

Door BeosBeing, dinsdag 7 december 2010 13:39

passeerwoord dan?

Door SizzLorr, maandag 6 december 2010 14:59

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 SizzLorr op maandag 6 december 2010 15:01]

Door Khildin, maandag 6 december 2010 15:06

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.

Door web_wil, maandag 6 december 2010 15:45

"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 web_wil op maandag 6 december 2010 16:11]

Door Radhe, maandag 6 december 2010 19:13

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!

Door BeosBeing, dinsdag 7 december 2010 13:46

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.

Door jospin, maandag 6 december 2010 15:32

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.

Door SizzLorr, maandag 6 december 2010 16:36

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.

Door dotnetpower, dinsdag 7 december 2010 09:09

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

Door padacom, maandag 6 december 2010 21:41

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

Door DJMaze, maandag 6 december 2010 15:31

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

Door dev10, maandag 6 december 2010 16:03

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

Door DJMaze, maandag 6 december 2010 18:06

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.

Door Sleep0rz, maandag 6 december 2010 16:14

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.

Door PhilipsFan, maandag 6 december 2010 14:48

"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".

Door cariolive23, maandag 6 december 2010 14:52

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.

Door Shadowhawk00, maandag 6 december 2010 15:26

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.

Door TGEN, maandag 6 december 2010 14:55

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

Door Terminal13, maandag 6 december 2010 14:56

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

Door kKaltUu, maandag 6 december 2010 16:30

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

Door jbtbnl, maandag 6 december 2010 18:02

Als ik even mag raden: er was geen projectmanager

Door ajakkes, maandag 6 december 2010 14:57

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.

Door Makkelijk, maandag 6 december 2010 15:06

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.

Door Woy, maandag 6 december 2010 15:16

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 )

Door BeosBeing, dinsdag 7 december 2010 14:07

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 dinsdag 7 december 2010 14:13]

Door Treenaks, maandag 6 december 2010 15:18

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

Door Garin84, maandag 6 december 2010 15:20

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.

Door i-chat, maandag 6 december 2010 15:27

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 ....

Door ajakkes, maandag 6 december 2010 15:58

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.

Door humbug, maandag 6 december 2010 16:17

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.

Door BeosBeing, dinsdag 7 december 2010 14:23

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.

Door MRTNbos, dinsdag 7 december 2010 12:52

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...

Door BeosBeing, dinsdag 7 december 2010 14:06

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.

Door Woy, maandag 6 december 2010 14:57

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.

Door AHBdV, maandag 6 december 2010 15:00

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.

Door i-chat, maandag 6 december 2010 15:30

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 )

Door ajakkes, maandag 6 december 2010 16:03

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.

Door mpkossen, maandag 6 december 2010 15:14

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

Door dmystic, maandag 6 december 2010 16:24

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.

Door Sedative, dinsdag 7 december 2010 00:09

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.

Door aikebah, dinsdag 7 december 2010 00:49

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)

Door BeosBeing, dinsdag 7 december 2010 14:30

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).

Door MRTNbos, dinsdag 7 december 2010 13:28

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.

Door sfranken, maandag 6 december 2010 14:49

Nou wil ik toch wel eens weten hoeveel M. de Hond verbruikt per jaar.

Door MisterLBP, maandag 6 december 2010 14:55

Ik zou eerder willen weten hoever hij achter loopt met zijn rekeningen

Door bonus, maandag 6 december 2010 15:34

Ik vind het al heel wat dat hij DAADWERKELIJK daar dan ook klant is

Door BeosBeing, dinsdag 7 december 2010 14:32

Hoorde waarschijnlijk bij zijn contract: Je mag zoveel electriciteit/gas verbruiken en krijgt xxx betaald. Daarnaast het de vraag of hijzelf klant is of zijn bedrijf.

Door Jism, maandag 6 december 2010 16:28

Volgens een kuchende klusjesman in regenjas is de energierekening van de nationale wijsvinger een kleine 14.500 kWh per jaar. Wow, da's ruim vier keer het landelijk gemiddelde.

bron

Door ingmaronline, maandag 6 december 2010 14:49

Ik zeg: Doen! Dat was inderdaad ook het eerste wat bij mij naar boven kwam

Toch niet heel fijn dat bedrijven back upjes maken van al je persoonlijke data en die dan níét heel goed beveiligen..

Door Robtimus, maandag 6 december 2010 14:57

Backups maken: prima.
Backups maken in XLS: een WTF op zich, daar zijn betere systemen / formaten voor.
Backups maken in XLS op een publieke server in een onafgeschermde locatie:

Dit is de fout van meerdere mensen:
- de ontwikkelaar(s) die de export doen naar XLS.
- de systeem-/websitebeheerder die de folder open heeft laten staan (waarschijnlijke communicatiefout met de ontwikkelaar(s)).
- de QA afdeling die dit niet heeft afgevangen voordat het systeem live ging.

Ik vind (als niet-NEM klant) dat hier toch wel een compensatie tegenover mag staan. Een maandje gratis stroom is een leuk begin.

Door i-chat, maandag 6 december 2010 15:32

een directe ontbinding van je contract een mooie 2e,

een duidelijk comunicatie (inclusief howto's) hoe je je wachtwoorden (ook op andere sites) moet weizige een 3e...

Door Xerion404, maandag 6 december 2010 16:59

doe mij maar die ontbinding in plaats van het maandje gratis

Door DaMayan, maandag 6 december 2010 16:55

Echt een backup lijkt mij dan ook erg onwaarschijnlijk.
Veel waarschijnlijker is het een tijdelijke export geweest voor bijvoorbeeld een kerstmailing die per ongeluk is blijven staan.

Door Robtimus, maandag 6 december 2010 17:00

Waarom staan de wachtwoorden er dan ook in? Voor een kerstmailing hoeft er alleen maar de naam + adres in te staan. Het klantnummer is misschien ook wel handig voor de automatische processen maar meer is echt niet nodig.

Door finraziel, maandag 6 december 2010 15:03

Dat heel goed mag je wel weglaten hoor...
Zoals iemand hierboven al zei is het inderdaad van de zotte dat die passwords überhaupt in plain text opgeslagen zijn, laat staan dat ze publiek toegankelijk zijn.

Door Jodocusdeunk, maandag 6 december 2010 14:50

Kan De Nederlandse Energiemaatschappij hier eigen ook boete voor krijgen?

Door Tijger, maandag 6 december 2010 15:01

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.

Door watercoolertje, maandag 6 december 2010 15:08

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 maandag 6 december 2010 19:00]

Door mpkossen, maandag 6 december 2010 15:16

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.

Door Matazj, maandag 6 december 2010 16:48

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 Matazj op maandag 6 december 2010 17:01]

Door ajakkes, maandag 6 december 2010 14:50

En, heeft De Hond zijn rekeningen netjes betaald? Hij krijgt korting zeker?

Laat maar, ik wil het niet echt weten.
De beste man heeft ook recht op een beperkte vorm van privacy.

Door BaRF, maandag 6 december 2010 14:51

toch een onaangenaam bedrijf ook hoor, mn zus is weetniet hoelang bezig geweest met een rekening die ze ten onrechte heeft gekregen, en ik ken ook iemand waar geld werd afgeschreven terwijl ze geen klant was, maar terugstorten was niet mogelijk - "want ze was geen klant"

ik zeg ook doen...

Door knirfie244, maandag 6 december 2010 14:56

Als iets onterecht wordt afgeschreven dan moet je ook bij je bank zijn, niet bij dat bedrijf...

Door Exorcist, maandag 6 december 2010 15:05

Offtopic, maar automatische incasso's kun je laten storneren. Evt. zelfs de incasserende partij blokkeren zodat ze helemaal geen geld meer van je rekening kunnen halen.

Door hAl, maandag 6 december 2010 15:19

Alleen als je er snel genoeg achterkomt.
Alsj e niet zo actief je rekening monitort dan kun je zo'n afboeking best missen.

Door Xerion404, maandag 6 december 2010 17:02

Je hebt er tegenwoordig behoorlijk lang de tijd voor, als ik het goed heb 56 dagen. Wanneer je zo lang je rekening niet monitort kun je het geld wel missen volgens mij...

Door aikebah, dinsdag 7 december 2010 00:55

13 maanden zul je bedoelen (er is namelijk geen sprake van een incasso-contract, je zult dus zeker succes hebben in de 'Melding Onterechte Incasso' procedure; de 56 dagen is voor het snel en eenvoudig laten terugboeken van een onterechte incasso)

http://www.currence.nl/nl...IncassoQAParticulier.aspx

Door drijfhout, maandag 6 december 2010 14:51

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!!!

Door highmastdon, maandag 6 december 2010 14:55

Dus jij bent nooit thuis 's nachts?

Door drijfhout, maandag 6 december 2010 15:02

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 maandag 6 december 2010 15:04]

Door Yezpahr, maandag 6 december 2010 16:13

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.

Door RobIII, maandag 6 december 2010 14:51

Door Da_moi, maandag 6 december 2010 15:33

"Whoops verkeerde plek..."

is anders precies wat bovenstaande programmeur zich inmiddels ook heeft bedacht...

« 1 2 3 4 5 6 7 »

Op dit item kan niet meer gereageerd worden.

15:07	Nieuwe beelden Killzone 3 uitgelekt
14:16	Britse overheid gaat investeren in snel internet

Nieuws I/O

Shortcuts

Categorieën

Lees meer over

Gerelateerde content

Gerelateerde jobs

Reacties

27-05 Nieuws

00:38 Productreviews

01:13 Vraag & Aanbod

25-05 Jobs

20:30 Etc.

02:18 Reacties

02:20 Forum

25-05 Gesponsorde acties

01:46 Tweakblogs

26-05 Computable headlines

25-05 CRN headlines