Huursite ikwilhuren.nu liet wachtwoorden in plaintext in debug-log staan

Door een kwetsbaarheid in een bemiddelingswebsite voor huurwoningen waren de gegevens van duizenden klanten zichtbaar. Een ethisch hacker ontdekte dat de e-mailadressen, wachtwoorden en inkomensgegevens bereikbaar waren door een slechte Apache-configuratie.

De kwetsbaarheid werd ontdekt door ethisch hacker Erwin Dirks, op Tweakers bekend als Defixje. Het lek was aanwezig op de website ikwilhuren.nu, een bemiddelingssite voor huurhuizen. Dat is een WordPress-website die wordt gehost op een verkeerd geconfigureerde Apache-server. Dirks ontdekte dat de website gebruikers die 'www.' in de url typten, met een verkeerde redirect naar een indexdirectory bracht. Op die manier wist hij verder in de directory van de website te kijken. In de directory ontdekte hij een debug-log met daarin de persoonsgegevens.

In de debug-log werd veel persoonlijke informatie van gebruikers opgeslagen. Het ging onder andere om de naam- en adresgegevens en het geslacht van de gebruikers van de site, maar ook het e-mailadres en telefoonnummer, informatie over het inkomen van de gebruiker en eventueel diens partner. Ook waren de gebruikersnaam en het wachtwoord te zien. Dat wachtwoord was in plaintext te lezen.

Het is niet helemaal duidelijk hoeveel informatie er exact is opgeslagen. De debug-log werd aangemaakt sinds zeker september van dit jaar en in totaal waren er in deze specifieke log 4784 unieke e-mailadressen te vinden. Of er ook voor die tijd een log werd bijgehouden, is niet duidelijk. De gegevens komen van mensen die een account aanmaakten op de website.

Ikwilhuren.nu is onderdeel van MVGM. Dat zegt tegen Tweakers dat het de desbetreffende log inmiddels offline heeft gehaald. Tweakers heeft gewacht met publicatie tot we konden verifiëren dat dat het geval was. De organisatie zegt dat zij 'de ontstane situatie betreurt' en haar excuses aanbiedt. "De debug-log is niet meer bereikbaar voor buitenstaanders en de persoonsgegevens worden niet meer gelogd", zegt de organisatie. Er is een wachtwoordreset uitgevoerd bij de getroffen gebruikers. Die hebben daar ook bericht van gekregen. MVGM heeft daarnaast melding gedaan bij de Autoriteit Persoonsgegevens, wat verplicht is bij dergelijke datalekken.

MVGM zegt dat het niet de bedoeling was wachtwoorden te loggen. "Het loggen van de wachtwoorden in plaintext had niet mogen gebeuren en was ook nooit de intentie. Dit was een ongewenst effect van het aanzetten van de debug-log voor het bekijken van warnings, errors en notices bij het migreren van de website naar een nieuwe server. Tot onze spijt is het ons niet opgevallen dat de debug-log deze informatie logde. Daarnaast is de log half september niet uitgezet toen de migratie naar de nieuwe server is afgerond." De fouten kwamen volgens de organisatie niet naar boven tijdens een pentest. Gebruikers wordt aangeraden een nieuw wachtwoord aan te maken. Dat wordt voortaan versleuteld opgeslagen en moet aan strengere minimumeisen voldoen.

Reacties (155)

[kftnl]

Natuurlijk niet goed en een slordige fout, maar ik verbaas me een beetje over de reacties hier. Dit is mij zelf ook niet overkomen, maar ik heb zelf ook weleens een domme fout gemaakt in mijn leven en ik denk dat dat voor wel meer mensen geldt.

Het gaat hier om wachtwoorden, ik denk dat het op een gegeven moment gewoon tijd wordt dat mensen zelf verantwoordelijk zijn voor het niet hergebruiken van wachtwoorden. Als je dat wel doet, prima, maar dat is dan je eigen probleem. We kunnen nu wel allemaal gaan zitten afgeven op kleine bedrijven als deze, maar ook grote organisaties waar ze wel weten wat ze doen hebben af en toe dit soort problemen.

Als mensen wachtwoorden niet hergebruiken is de scope van zo'n lek veel kleiner.

Ook jouw bedrijf kan dit gebeuren.

Als ik dan zie dat mensen hier maar oproepen dat ondernemers die zo een foutje maken de boel kunnen sluiten van de reaguurders: dus als bij jouw iemand in de administratie per ongeluk een klantenbestand naar de verkeerde emailt, dan vind jij het logisch dat jij en al jouw collega's hun baan kwijtraken hierdoor als straf?

[Reactie gewijzigd door kftnl op 24 juli 2024 22:11]

[defixje]

Het gaat hier zeker niet alleen om wachtwoorden maar om zeer persoonlijke gegeven.

En inderdaad, sommige reacties vind ik ook overdreven, ik heb natuurlijk al een tijdje contact met MVGM en ze kwamen mij zeer oprecht over en wat zij mij hebben uitgelegd over het ontstaan van de lek kwam bij mij ook plausibel over.

Wil het natuurlijk niet goedpraten dat niet, maar enige nuance is wel op zijn plaats.

[Gubbel]

Denk dat dit de beste manier is voor zo'n situatie.
Fouten komen nu eenmaal voor, ze hebben zelfs voor de migratie nog een pen-test laten uitvoeren waar dit toch best simpele lek niet naar voren kwam.

Komt op mij over alsof MVGM echt wel heeft gedaan wat ze moest en doen en naar weten gewoon goed hebben gehandeld. Vervolgens is snel gereageerd, is het probleem opgelost en zijn de jusite autoriteiten en personen ingeschakeld.

Jij en Tweakers brengen vervolgens geen nieuws naar buiten tot dit alles geverifieerd is. Klinkt mij als de perfecte situatie bij een helaas ongelukje.

[mannowlahn]

Ik heb anders helemaal niks mogen vernemen van MVGm dat mijn data naar buiten gekomen is, dat is wel schandelijk! Fouten maken kan, hoewel dit echt serieus achterlijk is, maar dan nog niet eens je gebruikers in te lichten vind ik nog kwalijker. Ze stellen wel dat we ingelicht zijn, maar er is niks verstuurd.

[SilentLucidity]

Misschien dat jij niet in de logs zat?

[mannowlahn]

Tja dat moet ik dan maar aannemen hè? Ook dan een mail in de trant van,’ u zal binnenkort lezen dat we een data lek hadden maar uw gegevens zijn niet publiekelijk gemaakt’ was op zijn minst netjes geweest.

[Gopher]

Ik heb niets gezegd

[Reactie gewijzigd door Gopher op 24 juli 2024 22:11]

[TripleQ]

Daarvoor zijn pasword managers uitgevonden...

[steffex]

Misschien dan even inlezen in password managers...

[RGAT]

Ik vermoed dat je niet de enige ter wereld bent die een telefoon (of zelfs 2) heeft, een laptop, een werklaptop, een werkdesktop, thuisserver, thuisdesktop, NAS enz enz dagelijks gebruikt, goed nieuws dus: je hoeft het wiel niet opnieuw uit te vinden, dat hebben een paar miljoen anderen al geregeld voor je

Oftewel even inlezen in wat wachtwoordmanagers zijn en hoe ze werken voordat je de aanname doet dat het onmogelijk is, overigens ook niet aannames doen bij security, gaat meestal fout zoals je ziet

[ari]

Je kunt de keuze maken om bijvoorbeeld je wachtwoorden voor werkgerelateerde zaken niet in je wachtwoordmanager te zetten, dat heb ik ook gedaan. Voordeel is voor mij dat dat maar één wachtwoord is, dus da's niet zo moeilijk. En anders kan het interessant zijn om eens het gesprek aan te gaan met een manager, wellicht staan ze er wel voor open om een wachtwoordmanager voor hun personeel aan te schaffen. Persoonlijk ben ik fan van BitWarden. Prima betaalbaar en open source, maar er zijn (veel) meer aanbieders.

[BezurK]

Dat is dus nou precies waar een goeie password manager goed in is. Netjes op al je apparaten je wachtwoorden onthouden en bij het aanmaken van een nieuw account een sterk en uniek wachtwoord voorstellen. En meteen opslaan. Er is serieus geen enkele reden om ooit nog wachtwoorden te hergebruiken of te moeten onthouden. Op geen enkel apparaat ever.

[Jeffrey_KL]

Laat password managers nou ook bestaan die cross platform werken. Daarnaast zou je je persoonlijke wachtwoorden niet nodig moeten zijn op een werk pc en zou je werk ook een vorm van een password manager moeten aanbieden. Of gebruiken jullie daar ook allemaal het zelfde wachtwoord voor alles werk gerelateerd?

[caipirinha]

Een spreadsheet in libreoffice op een read only encrypted USB stick, hoe simpel kun je het maken.
Doe ik al ruim 25 jaar zo, vroeger gebruikte ik daar een truecrypt volume voor.
Nu al >180 unieke passwords allemaal 30 karakters of langer, ik ga dat binnenkort maar eens naar een wat moderner alternatief migreren maar het gaat om het voorbeeld.

[Jarrean]

Dat wordt ook helemaal niet van je verwacht, er zijn voldoende hulpmiddelen (passwordmanagers) om dit eenvoudig voor elkaar te krijgen.

[DataGhost]

Dat moet je helemaal zelf weten natuurlijk, maar jij kan van buitenaf niet zien of een site de ingevoerde wachtwoorden netjes hasht, veilig beschermt, ze niet per ongeluk in debuglogs wegschrijft, of er geen admin is die alle mailadressen+wachtwoorden naar zichzelf stuurt elke keer bij het aanmaken/inloggen, of er geen malware op de site is gekomen die dat doet en of de boel niet uiteindelijk toch een keer op straat komt te liggen. Elke keer dat je een wachtwoord hergebruikt moet je maar hopen dat er niks ongeoorloofds mee gebeurt en er is voor jou geen enkele manier om daar achter te komen voordat het fout is gegaan. Het is eigenlijk niet anders dan je creditcardgegevens of bankpas+pincode vragen en hopen dat ik geen geld van je rekening afhaal.

Nu het bij deze site inzichtelijk is geweest moet je ervan uitgaan dat het wachtwoord wat je daar had openbaar is. Alle plekken waar je die specifieke combinatie mail+ww hebt gebruikt (voor veel personen is dat nog steeds "overal") moet je dan dat wachtwoord gaan veranderen of, als je daar geen zin in hebt, moet je dus een extra wachtwoord gaan onthouden. Dat kan je heel onredelijk vinden maar als dat vaak genoeg gebeurt zit je al makkelijk aan 30/40 unieke wachtwoorden onthouden, of 30/40x veranderen.

Dat "iedereen het doet" en "dat vroeger normaal was" betekent niet dat het ooit verstandig is geweest. Daarom inderdaad, een wachtwoordmanager. Ik heb meer dan 400 wachtwoorden die op geen enkele manier tot elkaar te herleiden zijn en bruteforcen kan je ook vergeten. Als ik een account op die site gehad zou hebben had ik me geen seconde zorgen gemaakt en gewoon dat wachtwoord veranderd naar iets anders, zonder dat ik dat weer hoef te onthouden.

[B_FORCE]

Ik vind het een heel zwak argument voor een bedrijf dat met persoonsgegevens omgaat.
Zodra je namelijk die kant op gaat, weet je van te voren als bedrijf dat je de zaken goed in orde moet hebben.
Met andere woorden, zul je dus extra tijd moeten steken in in beveiliging en het actief blijven troubleshooten en veilig houden van je website.
Probeer bv actief je eigen website te (laten) hacken.

Of zijn we inmiddels dingen zoals de Stint weer vergeten? Daar zou je ook kunnen beargumenteren dat de gebruiker niet zorgvuldig genoeg was.
Een rem kan immers toch falen (zelfde analogie als een website beveiliging die faalt).
Het punt wat hier gemaakt wordt is dat je de gebruiker nooit kunt vertrouwen voldoende kennis te hebben om zulk soort problemen te voorkomen.
Hetzelfde geldt voor een lader die niet ineens in de fik vliegt doordat mensen deze dagen lang in de hete zon leggen.
Vanuit de consument gezien kun je verwachten dat die vertrouwen heeft dat het wel snor zit.

Hoe dan ook in ALLE gevallen gaat het erom dat je als bedrijf verantwoordelijk bent voor de producten of diensten die je levert. (En niet om de onzinnige details voordat mensen daar weer pagina's over gaan schrijven).
Je weet de risico's voordat je daar aan begint als bedrijf.
Daarin falen noem ik gewoon laksheid of beunhazerij.

[DataGhost]

Ik vind het een heel zwak argument voor een klant die zijn eigen accounts dient te beschermen tegen ongeautoriseerde toegang. Je moet er altijd vanuit gaan dat er iets mis kan gaan, en zorgen dat de impact in zo'n geval minimaal is. Dat betekent dus overal unieke wachtwoorden gebruiken. Als klant geef je in principe jan en alleman een kopie van je huissleutels en staat vervolgens raar te kijken als een inbraak bij een van de honderden instanties met die kopie leidt tot het leegjatten van jouw huis. Ook elke login geef je ze een nieuwe kopie van je huissleutel zodat zij kunnen kijken of het dezelfde sleutel is, terwijl jij net zo goed een andere sleutel met ze had kunnen afspreken, er is immers nergens de verplichting dat het jouw huissleutel moet zijn. Liefst maak je gewoon een willekeurige sleutel per bedrijf en hang je dat bij jou thuis in een goed beveiligd sleutelkastje op. Dan kan niemand van bedrijf X hun kopie (van registratie of van elke inlog) aan bedrijf Y geven en zeggen dat ze jou zijn, omdat de sleutel niet klopt.

Dat wil niet zeggen dat bedrijven helemaal geen moeite hoeven te doen om jouw gegevens te beschermen, dat moeten ze nog steeds. Maar om te denken dat dat 100% goed gaat is echt ongelofelijk naïef. Een malafide site-admin kan hier al heftig misbruik van maken en met de noorderzon vertrokken zijn voordat goed duidelijk wordt wat er is gebeurd, en er is geen enkele beveiligingsmaatregel die hiertegen gaat helpen behalve wat terughoudendheid en verstand van jouzelf. Ik ga er voor elke site, ook Tweakers.net, vanuit dat ze de wachtwoorden plaintext opslaan, de beveiliging slecht is en de admins niet te vertrouwen. Gebeurt er iets met dat wachtwoord, is de impact beperkt tot die ene site, en op het moment dat het wachtwoord daar uitlekt is er vaak al meer aan de hand waardoor dat wachtwoord niet eens nodig is om op die site in te loggen of acties uit te voeren onder mijn naam.

[Reactie gewijzigd door DataGhost op 24 juli 2024 22:11]

[DonJunior]

Wekelijks zijn dergelijke datalekken in het nieuws. Je zou zeggen dat men ondertussen wel gewaarschuwd is. Ik zou als bedrijf zijnde dus pro-actief mijn eigen systemen controleren. Dan had men al heel snel kunnen zien dat dergelijke data wordt gelogd en dat er wachtwoorden onversleuteld over de lijn gaan en in de database staan. Dan hadden al de alarmbellen af moeten gaan.
Nu gaan ze pas achteraf actie ondernemen.

Tuurlijk, fouten maken mag.. maar een gewaarschuwd mens telt voor twee. Laat staan als je wekelijks gewaarschuwd wordt door dergelijke nieuwsberichten.

[robvh99]

Als ik de tekst lees staat dat
De fouten kwamen volgens de organisatie niet naar boven tijdens een pentest.
Ze hebben dus blijkbaar wel een test gedaan /laten doen, maar daarbij is fout niet gevonden.
Zegt mogelijk om wat over de kwaliteit van de testers, maar dat is een ander verhaal.

[defixje]

Dit specifieke lek heeft nooit naar voren kunnen komen bij een pentest. Wel bij een goede code review dat dan weer wel.

[Oon]

Ook jouw bedrijf kan dit gebeuren.

Dat is onzin. Een goeie developer zou nooit debug logs in de webroot laten staan. Met een correct ingestelde server zijn alleen de statische assets en entry points beschikbaar binnen de webroot, en alle andere bestanden erbuiten.

Daarnaast zou ook in een debug log nooit een wachtwoord moeten staan, zeker niet plaintext. Zelfs al dump je hele requests, dan nog is het heel makkelijk om hier wachtwoordvelden uit te filteren.

Het gaat hier gewoon om incompetentie van de developer, daar is geen excuus voor.

[Bas.Bas.Bas]

Je hebt helemaal gelijk, maar zoals jij ook gemerkt hebt zitten er een hoop mensen op tweakers die nooit fouten maken en blijkbaar al hun code perfect zonder fouten opleveren. Deze code is ook 100% getest. Ik weet niet waar deze mensen werken maar ik wil er ook graag zitten.

[DataGhost]

Zomaar "je wachtwoord" over het lijntje gooien naar iedereen die erom vraagt is ook een vorm van nalatigheid. Daarmee praat ik niet goed wat er gebeurd is maar je hebt zelf alles in de hand om eventuele schade te beperken. Het is een beetje als autorijden zonder gordel om, gaat prima totdat iemand buiten jouw schuld om frontaal op je klapt. Vroeger was het de norm en waren gordels maar raar en onhandig, daar zijn we ondertussen van teruggekomen. Hoog tijd dat dat met password reuse ook gebeurt.

[DonJunior]

Als je op de website komt zul je toch moeten inloggen met je wachtwoord? Ik snap het hele vergelijk met de autogordel daarom niet helemaal. Hoe kan men hier nou als gebruiker enigszins iets worden verweten.. dat snap ik echt niet. Tuurlijk als je overal hetzelfde wachtwoord gebruikt.. maar wie zegt dat daar hier sprake van is? Dat is iets dat je zelf erbij hebt getrokken maar dat staat los van de nalatigheid van het bedrijf in kwestie.

[DataGhost]

Het voornaamste issue van het lekken van wachtwoorden en het moeten hashen en salten van wachtwoorden in de database is dat mensen wachtwoorden hergebruiken. Daarom is er "vroeger" een hele hetze ontstaan tegen sites die plaintext wachtwoorden opslaan, omdat gedacht was dat de database de enige attack-vector was en het gangbaar was dat iedereen maar 1 wachtwoord had voor alle services ("geen autogordel"). Hierbij werd compleet voorbijgegaan aan wat gebruikers zelf zouden kunnen en moeten doen, namelijk verschillende wachtwoorden gebruiken ("autogordel omdoen") terwijl over de praktische uitwerking nog niet goed was nagedacht. De gordel was nog niet uitgevonden zegmaar. Als iedereen gewoon netjes z'n wachtwoordmanagement op orde had, ik weet het dat is op dit moment een utopie, blijft dit gewoon beperkt tot slechts die ene site, en hoeven berichten als deze een stuk minder heftig in het nieuws te komen qua toonzetting. Dan gaat het over "gewoon" een inbraak, terwijl er anders, zoals nu als er wachtwoorden in het spel zijn, veel heftigere reacties zijn over wat een grove nalatigheid de sitebeheerders is aan te rekenen waar het nog net niet over gevangenisstraffen gaat.

Zoals ik elders al heb gereageerd, in het geval van *mijn* account vind ik het op de meeste websites geen enkel probleem als het wachtwoord plaintext wordt opgeslagen en alle beheerders dat zonder problemen in kunnen zien. Beheerders kunnen doorgaans toch al alles "namens mij", en op het moment dat een indringer bij die wachtwoorden weet te komen is er vaak (niet altijd) al genoeg mis om mijn wachtwoord niet eens nodig te hebben om gebruik te maken van mijn account. En natuurlijk heb ik voor elke site unieke, niet-bruteforcebare wachtwoorden. Neemt niet weg dat een klein beetje hulp zoals gehasht opslaan van wachtwoorden direct een mogelijke attack vector significant verkleint maar zoals je ziet is dat geen garantie dat wachtwoorden op geen enkel moment in te zien zijn waardoor ze in een debuglog terecht komen. Als je https gebruikt wordt je wachtwoord netjes versleuteld over de lijn gestuurd maar is dan in de site-software alsnog plaintext beschikbaar.

[Kettrick]

Er staat nergens dat het plaintext over het internet gaat, dat is onwaarschijnlijk, maar tegen de tijd dat het in de logs komt is het wel plaintext. Er staat ook nergens dat het plaintext opgeslagen wordt.

[DonJunior]

Het staat er niet specifiek.. maar dan komt het stukje begrijpend lezen om de hoek.

Dat wordt voortaan versleuteld opgeslagen

.. ergo dat was nog niet het geval.

[basdej]

Ik heb ook gebruikt van deze website voor mijn huurwoning. Hoe kan ik nu checken of ik een van de getroffen gebruikers ben? In het artikel is niet duidelijk dat ze de getroffenen gaan informeren.

[defixje]

MVGM heeft aan mij aangegeven dat iedereen die in die log voorkwam een mail heeft ontvangen en dat de wachtwoorden gereset zijn.

[basdej]

Oke dank voor de toelichting! dan ben ik in ieder geval safe Mag wellicht ook door Tweakers aan het artikel toegevoegd worden.

[Verwijderd]

Ik zou het toch doen, een mens kan altijd een logbestandje missen, of misschien heeft ie wel in een log gestaan die ze nu niet meer hebben.

[TijsZonderH]

Gedaan!

[kodak]

Er is niet gezegd dat je dan safe bent. Er lijkt namelijk ook onduidelijkheid wanneer dit probleem is begonnen. De kans is dus kleiner dat het ook om jou ging.
Zoals @TommyboyNL ook aangeeft is er ook nog het probleem dat de wachtwoorden onversleuteld verwerkt werden en niet duidelijk is wanneer dat dan wel gebeurde.
Het kan hoe dan ook geen kwaad om je wachtwoord dus aan te passen.

[Reactie gewijzigd door kodak op 24 juli 2024 22:11]

[jelcon]

Lijkt me vrij duidelijk dat je het beste, ongeacht of je getroffen bent of niet, je wachtwoorden aanpast als je voor meerdere sites dezelfde wachtwoorden gebruikt, ik zou persoonlijk niet wachten op een instantie die zijn zaken zo slecht op orde heeft

[cariolive23]

Lijkt me vrij duidelijk dat je het beste, ongeacht of je getroffen bent of niet, je wachtwoorden aanpast als je voor meerdere sites dezelfde wachtwoorden gebruikt,

Ik mag toch hopen dat mensen anno 2020 voor iedere website een apart wachtwoord gebruiken! Met een wachtwoordmanager is dat zeer eenvoudig te realiseren. Volgens is dit standaard in Safari en Chrome op OSX, maar ik weet niet hoe andere browsers en OS-en er mee omgaan.

Dat heeft ook als voordeel dat phishingwebsites eenvoudiger zijn te herkennen, jouw browser herkent de website niet en biedt dus geen passend userid/wachtwoord aan. Dan krijg je direct een "hoe kan dat nou, mijn wachtwoord wordt niet ingevuld?"-moment.

[ronhorst]

In de meest ideale wereld zou iedereen voor elke site een ander wachtwoord gebruiken. Helaas is dat niet zo en zijn er veel mensen die 1 wachtwoord heeft. Met geluk wordt er nog afgewisseld met soms een hoofdletter, soms een ! of een ander cijfer.

Ik verwacht dat het percentage dat hier zit en wisselende wachtwoorden gebruikt hoog is maar durf het niet voor 100% zeker te zijn. Maar niet tweakers is dat percentage veel lager. zie hieronder: voor wat bronnen.

nieuws: 'Veertig procent van Nederlanders hergebruikt wachtwoord' - update
https://www.metronieuws.n...ijd-hetzelfde-wachtwoord/

[PatrickH89]

Ik zou nog verder willen gaan in dat we in een ideale wereld helemaal geen password authenticatie zouden hebben. Helaas hebben de alternatieven ook allemaal weer hun eigen nadelen waardoor we het er toch nog even mee zullen moeten doen.

[jelcon]

Ik mag toch hopen dat mensen anno 2020 voor iedere website een apart wachtwoord gebruiken

Het spijt me, ik moet je uit een bubbel halen, groot deel van de mensen die ik ken, waaronder mensen die zeker niet dom zijn, hebben gewoon vrolijk één wachtwoord anno 2020.
Vaak wel met variaties erop, maar wel altijd ongeveer dezelfde

[Vayra]

AVG verzoek indienen en verwijdering eisen. Je wil de dienst niet meer gebruiken.

[Reactie gewijzigd door Vayra op 24 juli 2024 22:11]

[Polydeukes]

Waarom niet? Je kunt op je vingers natellen dat ze dit probleem zsm willen oplossen en herhaling willen voorkomen. Dus als 't goed is heb je binnen afzienbare tijd gewoon een website waar je gegevens veilig worden verwerkt. Beter een bedrijf dat fouten erkent en handelt, dan niet weten of je gegevens veilig zijn imho.

[P_Tingen]

Denk ik niet. Noem me cynisch, maar ik zie hier twee problemen:
1) De debuglogging is te lezen
2) De logging bevat plaintext wachtwoorden.

Voor het geval de ernst van nr 2 niet duidelijk is, herhaal ik hem even:
2) De logging bevat plaintext wachtwoorden.

PLAINTEXT! Die staan dus ook plaintext ergens in hun database en dat gaan ze niet 123 oplossen. Die debugfiles hebben ze zo afgeschermd, maar je wachtwoord blijft ongetwijfeld in plaintext verwerkt worden.

[deadinspace]

PLAINTEXT! Die staan dus ook plaintext ergens in hun database en dat gaan ze niet 123 oplossen.

Die conclusie kun je niet trekken met de informatie die hier gegeven is.

Ik weet niet wat er in die logs stond, maar het kan zijn dat daar requests gelogd werden, inclusief POST body. Dat is geen gek scenario voor debugging. Dan kan bij een login bijvoorbeeld POST /login {"username": "P_Tingen", "password": "welkom123"} gelogd worden. Daarna wordt dan de login door de applicatie afgehandeld, wat prima kan bestaan uit een check tegen een hash in de database.

Begrijp me niet verkeerd, het zou ook kunnen dat wachtwoorden plain-text in de database staan, dat kan ik niet controleren. Met de informatie die we hier hebben kunnen we daar simpelweg geen conclusie over trekken.

[P_Tingen]

Voor debugging in een lokale omgeving niet nee, maar je wil in een productieomgeving toch geen wachtwoorden in plain tekst hebben?

[thomas1907]

En dat geeft ikwilhuren.nu toch ook aan? Ze hebben dit niet expres aangezet maar nooit uitgezet na een migratie.
Het is inmiddels opgelost (Geen gegevens in die logging meer) en melding gedaan bij AP. Zo hoort het ook gedaan te worden.

[Reactie gewijzigd door thomas1907 op 24 juli 2024 22:11]

[Vayra]

Totdat ze weer migreren

Oeps... tja... hallo, we hadden het toch uit staan?
Prutsers.

[Reactie gewijzigd door Vayra op 24 juli 2024 22:11]

[Andreplusplus]

Uhm.... wat typ jij dan in als je je wachtwoord moet invullen?

[deadinspace]

Voor debugging in een lokale omgeving niet nee, maar je wil in een productieomgeving toch geen wachtwoorden in plain tekst hebben?

Normaal gesproken wordt het wachtwoord verstuurd over een versleutelde HTTPS verbinding, waarna het plain-text op de server aanwezig is, gehashed kan worden, en vergeleken kan worden met een opgeslagen hash.

Het is natuurlijk niet wenselijk om die wachtwoorden dan plain-text te loggen, het zegt alleen weinig over de rest van de situatie (inclusief of de wachtwoorden plain-text in de DB staan of niet).

[robg1984]

Het kan natuurlijk als plain opgeslagen zijn na invoeren van het wachtwoord in een input waarbij het wel versleuteld is opgeslagen in de database..

[Kingeling]

Eens! Juist omdat een bedrijf laat zien dat het dit belangrijk vindt zou je ze dit vertrouwen kunnen geven. Tenzij er natuurlijk aanwijzingen zijn dat ze het verder weinig serieus nemen met beveiliging natuurlijk, maar ik ben ook wat alergisch voor de binaire reactie.

[Quintiemero]

‘Laat zien het dit belangrijk vindt, zou je ze dit vertrouwen kunnen geven’.

Dat lijkt me toch redelijk vanzelfsprekend.. hun marketing werkt blijkbaar

Kan best begrijpen dat er mensen zijn die niet meer van hun dienst gebruik willen maken.

[DonJunior]

Juist omdat een bedrijf laat zien dat het dit belangrijk vindt

Sorry? Dan hadden ze dat al veel eerder moeten doen. Datalekken zijn wekelijks in het nieuws.. dan ga je als bedrijf toch defensief je beveiliging controleren? Niet pas in actie komen als er een lek is gevonden. Wachtwoorden plain opslaan hadden ze allang niet moeten doen en dat hadden ze al veel eerder kunnen zien.

Nee ik zou niet willen stellen dat ze dit belangrijk vinden. Sterker nog ze lijken me eerder laks.. nu ze betrapt zijn gaan ze ineens hard aan de slag.. beetje mosterd na de maaltijd wat mij betreft.

[Vayra]

Ach hou toch op. Als je een structuur in je bedrijf hebt dat dit soort grove nalatigheid niet al in het ontwikkelstadium afvangt, ben je geen knip voor de neus waard.

Dit is zó basic.

Ik geloof wel in tweede kansen... maar er zijn uitzonderingen. Hoe ga je dit nu wel goed doen dan, dat vergt minstens een gigantische, 180 graden cultuuromslag. Als je al even in bedrijven rondloopt dan weet je dat dat niet 1.2.3. geregeld is, zo'n omslag. Als het je uberhaupt al lukt.

[Reactie gewijzigd door Vayra op 24 juli 2024 22:11]

[TommyboyNL]

Aangezien er geinsinueerd wordt dat wachtwoorden onversleuteld opgeslagen waren, is het sowieso verstandig om je wachtwoord daar aan te passen.

[Polydeukes]

Het bedrijf heeft alle wachtwoorden van de getroffen accounts al gereset.

[TommyboyNL]

Alleen de accounts waarvan de wachtwoorden in de logs stonden, niet alle accounts. Aangezien de wachtwoorden onversleuteld/ongehashed in de DB stonden, dien je die ook gewoon als "uitgelekt" te beschouwen.

[WoutervOorschot]

Ze stonden in een logfile, dat hoeft niet te betekenen dat ze onversleuteld in een database oid staan opgeslagen. Anders was dat het nieuws waarschijnlijk wel geweest.

[TommyboyNL]

In het artikel staat impliciet dat dat dus wél het geval was:
"Gebruikers wordt aangeraden een nieuw wachtwoord aan te maken. Dat wordt voortaan versleuteld opgeslagen en moet aan strengere minimumeisen voldoen."
Sleutelwoord: Voortaan. Voorheen dus niet.

[WoutervOorschot]

Ah daar had ik overheen gelezen, nou in ieder geval netjes dat ze het nu snel gaan aanpakken.

[DonJunior]

Beetje laat om als bedrijf nu pas actie te gaan ondernemen m.b.t o versleutelde wachtwoorden. Hoe vaak zijn dergelijke lekken nu al in het nieuws geweest?!
Dit riekt een beetje naar: 'Als het kalf verdronken is dempt men de put'
Nu zijn ze 'betrapt' en gaan ze ineens wel actie ondernemen.
Wachtwoorden onversleuteld opslaan mag best een flinke boete op staan voor dergelijke bedrijven.

[Andreplusplus]

Dus een woordkeuze van een journalist bepaalt hoe het echt zit? Ik verbaas me over zoveel gebrek aan kennis hier (om maar geen 'domheid' te gebruiken)

[Aardwolf]

Naast het punt nog: "De debug-log werd aangemaakt sinds zeker september van dit jaar". Kan het dan ook niet al eerder zijn gebeurd, bijvoorbeeld een ander debug-log die nu offline was maar bijv. in augustus in te zien was... of in januari, of in augustus 2018, etc?
Wat is de moeite om iedereen zo'n reset te geven vraag ik me af. Een selectie maken lijkt me even veel werk, zo niet meer.

[Freekers]

Is er melding gemaakt bij de AP van een datalek? Lijkt me namelijk wel op z'n plaats hier.

[defixje]

Jazeker. Ik moet zeggen dat MVGM heel snel gehandeld heeft en ze waren heel behulpzaam en aardig tegen mij. Ook hebben zij melding gedaan bij het AP.

[Bender]

Het klinkt alsof je verbaast bent dat ze aardig tegen je zijn, kan ik daar uit opmaken dat dat vaak niet zo is terwijl jij iets kenbaar maakt (en geen misbruik maakt)?

[defixje]

Ik heb wel een lekken gemeld bij bedrijven en die gingen schelden door de telefoon en aangifte doen bij de politie. Die heb je er helaas ook bij zitten.

[Bender]

Is er ooit aangifte gedaan bij de politie tegen je in een dergelijk geval?

Zou dom zou zijn om tegen jou aangifte te doen naar mijn idee gezien ze zelfs vele grovere fouten begaan.

[defixje]

Jazeker, dat is al meerdere keren gebeurd. Alleen ik hou alles netjes bij wat ik doe en heb gelukkig genoeg referenties die kunnen aantonen dat ik niks kwalijks doe en hun altijd goed geholpen heb.

[mcDavid]

Ik moet eerlijk zeggen dat ik persoonlijk ook hoogstverbaasd ben dat MVGM "aardig" kan zijn en "snel gehandeld heeft".

Mijn ervaring als huurder via MVGM zijn nogal... anders, laat ik het zo uitdrukken.

[Reactie gewijzigd door mcDavid op 24 juli 2024 22:11]

[TijsZonderH]

Eens, dat verdient lof. Bedrijven reageren ook tegen ons lang niet altijd zo snel en uitgebreid als MVGM nu deed.

[CorbataGames]

En toch zou ik het aanraden wel zo aardig en uitgebreid te reageren. Je komt er een stuk beter uit in de geschreven stukken en als ik nu zo lees wat er allemaal is gedaan na de melding, geloof ik veel eerder dat dit goed is afgehandeld en daadwerkelijk een ongelukkig incident is.

Bij partijen die moeilijk gaan lopen doen, krijg je een veel onsympathieker gevoel en zou ik mijn twijfels hebben om er zaken mee te doen.

Hulde!

[kryptonice]

Nu nog snel, aardig en behulpzaam in hun vakgebied

[pancake82]

De definitie van datalek is dat de data werkelijk ontvreemd is.

Vanuit mijn optiek vind ik het gek dat dit bedrijf nu scheef in het nieuws staat dat er een "data lek" is waar andere Vendors er me weg komen dat het een "vulnerability" is. Microsoft is hier een goed voorbeeld van.

Iedereen maakt fouten, en dit bedrijf verdiend credits voor openheid van zaken en het snelle handelen dankzij Erwin Dirks.
Velen kunnen een voorbeeld nemen aan MVGM

[TommyboyNL]

Nee, dat is die niet. Persoonsgegevens onbedoeld vernietigen is ook een datalek:
"Bij een datalek gaat het om toegang tot of vernietiging, wijziging of vrijkomen van persoonsgegevens bij een organisatie zonder dat dit de bedoeling is van deze organisatie. Of zonder dat dit wettelijk is toegestaan."
Bron: https://autoriteitpersoon...ing/meldplicht-datalekken

[whitefox]

Dat komt ook doordat er in standaard software die Microsoft (en andere bedrijven) levert geen persoonsgegevens zijn opgeslagen. Dat wordt gedaan door haar gebruikers na ingebruikname, dus is het slechts een kwetsbaarheid. Die kwetsbaarheid kan wel leiden tot een datalek bij de gebruikers zelf.

[defixje]

Ook ik vind dat MVGM super gehandeld heeft,en ik vind ook dat andere hier een voorbeeld aan kunnen nemen.

[effem]

Artikel gelezen?

MVGM heeft daarnaast melding gedaan bij de Autoriteit Persoonsgegevens, wat verplicht is bij dergelijke datalekken.

[Luchtbakker]

Als je zo slecht je website onder controle hebt maar wel met persoonsgegevens werkt, vind ik dat je als site direct gesloten moet worden.

Het opzetten van een website is 1, maar als je er weet dat je met persoonsgegevens gaat werken dan vind ik dat je echt 4x na moet denken voor je start, of anders staat er een giga boete tegenover.

[kodak]

Je noemt het zo slecht maar waar meet je dat dan aan? Als iets geen fout heeft is het heel goed en als iemand een keer een fout maakt terwijl er nog zo veel gedaan is om het te voorkomen dan is het al heel slecht?
Het probleem is dat fouten maken menselijk is en dus niet valt te voorkomen. Dat het niet de bedoeling is dat er fouten gemaakt worden is wat anders dan er te weinig tegen doen. Daarom telt vaak ook de omstandigheden mee bij bestraffen. Anders kan je net zo goed de regels wel afschaffen en de verwerking van persoonsgegevens laten aan bedrijven die er niet zo veel om geven failliet te gaan. Ondertussen laten ze dan de minder aansprakelijke aandeelhouders en personeel genieten van de winst tot het bedrijf de megaboete mag betalen of dicht moet. Ik denk niet dat we veel hebben aan dit soort yolo straffen.

[Reactie gewijzigd door kodak op 24 juli 2024 22:11]

[theduke1989]

Inderdaad dit soort websites horen flink gestraft te worden. een waarschuwing is hier niks bij.
Gewoon een schade van 1 ton of meer geven dan leren ze het wel. Dit zijn ook bedrijven die voor de overheid verhuren aan mensen dus ja moet je extra voorzichzig zijn. en niet alleen privaat volgens mij.

[NielsFL]

Ben wel benieuwd wie de website gemaakt heeft. Formeel is MVGM natuurlijk aansprakelijk, maar als ze de website hebben uitbesteed wil ik toch wel graag weten wie dit soort broddelwerk aflevert. Een beetje logger laat namelijk geen wachtwoorden zien, ook niet op debug niveau.

[Carharttguy]

Een beetje logger laat namelijk geen wachtwoorden zien, ook niet op debug niveau.

Als je Apache gewoon alles laat loggen, dus ook POST parameters, is het toch logisch dat wachtwoorden daar ook tussen staan?

[Cybje]

Het vervelende alleen bij dit soort organisaties is dat over het algemeen de boete uiteindelijk bij de huurder van de woningen komt te liggen. MVGM wil gewoon winst maken, minimaal kostendekkend zijn. Dus als zij hogere kosten hebben, verhogen ze gewoon hun bemiddelingskosten of welke kosten ze ook maar rekenen bij een aanmelding voor een huurwoning.

Neem me niet verkeerd, ik ben het zeker met je eens, dit soort organisaties moeten de fouten die ze maken echt voelen (en dus gemotiveerd worden hun zaakjes op orde te hebben). Maar meestal zijn het niet degene die de fouten maken (of de eindverantwoordelijke) waar ze de boete voelen.

[theduke1989]

Dat hoort de AVG dan tegen te houden. De huurder zou hier niet voor de dupe moeten zijn.

[FreshMaker]

Dan zou een oplossing kunnen zijn een boete EN de eerste xx jaar verbod op prijsverhogingen in het portfolio

Maar dan neemt een kennis het bedrijf 'over' en begint het spel opnieuw

[Verwijderd]

...de boete uiteindelijk bij de huurder van de woningen komt te liggen. ... als zij hogere kosten hebben, verhogen ze gewoon hun bemiddelingskosten

Ik lees dergelijke onzinredeneringen wel eens vaker hier op tweakers. Zo werkt het gewoon niet. Als een organisatie hogere kosten maakt dan de concurrentie en die doorrekent aan de klanten prijst ze zichzelf uit de markt.

[Cybje]

Als MVGM daadwerkelijk concurrentie had, waren ze al lang verdwenen van de markt. Ik huur toevallig via MVGM en ze zijn echt dramatisch slecht. Tot het punt dat ik de eigenaar van het complex heb gevraagd een andere beheerder te gaan zoeken. En ik ben lang niet de enige hier in het complex met die mening, om het dan nog niet eens over de mensen in andere appartementencomplexen te hebben. Maar er lijkt gewoon geen goede concurrent voor te zijn. Als je als pensioenfonds of wat dan ook dit soort gebouwen bezit voor verhuur, lijkt MVGM de meest logische beheerder te zijn in regio Amsterdam.

Als hun bemiddelingskosten 2x zo hoog waren geweest, had ik vermoedelijk nog steeds weinig anders gekund dan via MVGM huren. Ze beheren gewoon alle goede en moderne huurwoningen hier lijkt wel.

[Reactie gewijzigd door Cybje op 24 juli 2024 22:11]

[johanl79]

[...]

Ik lees dergelijke onzinredeneringen wel eens vaker hier op tweakers. Zo werkt het gewoon niet. Als een organisatie hogere kosten maakt dan de concurrentie en die doorrekent aan de klanten prijst ze zichzelf uit de markt.

Zoals jij redeneert werkt het ook gewoon niet. Niet iedereen heeft de luxe zo maar even te kunnen verhuizen (en dan inderdaad hopen dat je niet via MVGM huurt in de toekomst).

[Aardwolf]

Inderdaad, wat een onzin zeg. Alsof de huurmarkt zo breed is dat je ruim kunt kiezen bij welke vereniging je wilt. Meestal kies je eerst in welke plaats, daarna welke wijk en welk huis... de vereniging kies je (als je die keuze überhaupt nog hebt) pas als laatste, die is meestal lijkt me ondergeschikt in deze verdringende markt. Denk in de stad misschien meer keuze in "aanbieders", maar hier op het platteland is er maar 1 vereniging en soms 2 die meerdere plaatsen doet. Van echt (veel) concurrentie is dus ook geen sprake.

[Reactie gewijzigd door Aardwolf op 24 juli 2024 22:11]

[HenkEisDS]

Inderdaad. Doe maar een toets voordat je met een unmanaged website aan de slag mag.

Gebeurt ook als je een hypotheek wilt aanvragen (probeer dat maar eens zonder adviseur), kan dus hier ook prima.

[watercoolertje]

Gebeurt ook als je een hypotheek wilt aanvragen (probeer dat maar eens zonder adviseur)

Kan ook prima zonder hoor, sterker nog de Hypotheker kreeg het niet voor elkaar, ikzelf wel

Maar dat zijn privé-zaken, die website is commercieel en daar mag idd wat mij betreft een adviseur voor verplicht worden als er commerciele activiteiten rondom personsgegevens zijn.

[Reactie gewijzigd door watercoolertje op 24 juli 2024 22:11]

[brabbelaar]

100% eens. Dit is zó primitief, altijd al en anno 2020 al helemaal. Er bestaat toch ook een wettelijke plicht om zorgvuldig met gegevens om te gaan? Dit lijkt me daar sowieso buiten vallen.

[Asitis]

Dit is geloof ik ook precies waar de AVG wetgeving een rol in speelt.

[kftnl]

Elke website werkt met persoonsgegevens. IP adres is ook een persoonsgegeven.

Denk dat de mensen die hier zo geschokt door zijn helemaal zouden flippen als ze zouden zien wat er allemaal in een telefoonboek stond.

[aidanl]

Deels mee eens. Wanneer een bedrijf willens en wetens slecht omgaan met persoonsgegevens mag die wat bij betreft direct gesloten en failliet verklaard worden.

Echter, wanneer een bedrijf wel de moeite neemt, bovendien ook penetratie tests laat uitvoeren, tja het blijft mensen werk. En waar mensen werken worden fouten gemaakt. In dit geval hebben ze direct op de melding gehandeld en maatregelen genomen. Daarnaast is er dus ook melding gedaan bij het AP (zie antwoord van @defixje hierboven). In een dergelijk geval vind ik het dan ook kwalijk om direct een bedrijf de grond in te helpen. Oftewel, je kan niet alles en iedereen over 1 kam scheren.

[Vayra]

Gewoon gedwongen sluiting van de hele toko, niet alleen de website. Je hebt je kans verspeeld. Begin maar opnieuw na je faillissement.

Dit is grove nalatigheid. Hier passen geen waarschuwingen meer anno 2020, en eigenlijk tien jaar geleden ook al niet.

Dit doet denken aan de inefficentie bij de GGDs, aan het RIVM met zijn storingen, aan... nou ja vul het in, dik 50% van de IT in Nederland. En dat komt allemaal door die pappen- en nathouden aanpak.

[Reactie gewijzigd door Vayra op 24 juli 2024 22:11]

[Core2016]

Als iedereen zo zou denken ontploft de wereld over 237 dagen. Its true.

[Vayra]

Zou me niet verbazen, je moet eens om je heen kijken wat dat betreft. Dit kan heel prima de aanloop naar een groot conflict zijn. Ondertussen zijn wij nog aan het bekijken hoeveel tanks Duitsland ons hopelijk nog kan lenen maar hebben we niet eens personeel om ze te gebruiken.

Nee, gaat best goed hoor, met die basale zaken die een land geregeld dient te hebben en die zachte polderhand als het gaat om problemen oplossen. Het benoemen alleen al levert een jaar discussie op terwijl iedereen eigenlijk al wel weet hoe laat het is.

Gisteren nog een ontluisterend stuk in de Volkskrant over hoe men aan het klooien is met het PGB. Meer van hetzelfde. Je denkt dat het niet erger kan? Jawel hoor. Lezen! Je lacht je kapot...
https://www.volkskrant.nl...ge-het-is-kafka~b3b2df61/

[Reactie gewijzigd door Vayra op 24 juli 2024 22:11]

[bazzi]

Gebruikers wordt aangeraden een nieuw wachtwoord aan te maken. Dat wordt voortaan versleuteld opgeslagen en moet aan strengere minimumeisen voldoen.

Voortaan versleuteld opgeslagen? Dat doet mij af vragen of het wel in de database versleuteld was opgeslagen.... Dat zou het nog veel beschamender maken...

[Tweakert2020]

Hoef je niet af te vragen, er staat voortaan, dat betekend voorheen niet.

[StefanJanssen]

Daarmee kan ook bedoeld worden: In de log versleuteld opgeslagen

[brabbelaar]

Hoe krijg je het plain text in een debug file als het in de database wél versleuteld is? Er one way encryption is the way. Zo'n wachtwoord moet nooit te achterhalen zijn.

[watercoolertje]

Je kan prima plain wachtwoorden opslaan ook al heb je in de database enkel hashes (one way encryption) van die wachtwoorden staan.

De gebruikers hoeven het enkel naar je te sturen (wat bij inloggen dus gebeurd) en de server verifieert dan of dat wachtword omgezet naar een hash hetzelfde is als die in de database.

Komen die overeen? DDan weet je op dat moment dus en de hash en de plaintekst versie en zou je dat kunnen loggen (zou absoluut niet moeten!).

[Reactie gewijzigd door watercoolertje op 24 juli 2024 22:11]

[bazzi]

naja als je de $_POST dumpt, dan krijg je het wel erin. Want meestal is de $_POST unencrypt en wordt het daarna in de code geencrypt....

[kftnl]

Ja, jij zit wachtwoorden netjes uit core-dumps te editen? Er zijn allerlei soorten logs.

[Reactie gewijzigd door kftnl op 24 juli 2024 22:11]

[TommyboyNL]

"Gebruikers wordt aangeraden een nieuw wachtwoord aan te maken. Dat wordt voortaan versleuteld opgeslagen en moet aan strengere minimumeisen voldoen."
PARDON!? Zeggen ze nu serieus dat ze wachtwoorden in plain-text opgeslagen hadden? Dat schept weinig vertrouwen in de versleuteling die ze gaan gebruiken, dat zal wel unsalted MD5 of ROT26 zijn...

[brabbelaar]

Ja en het wachtwoord moet aan strengere minimumeisen voldoen. Alsof het nog uitmaakt dat je wachtwoord AAA is ipv )S034IuSL?!3@#!_4 of iets dergelijks wanneer je het in platte tekst opslaat.

[mrwiggs]

Uhm ja? De eerste is simpel te kraken met brute force, de tweede niet.

Je zou eerst de database moeten hacken als het geen verschil zou moeten maken.

[watercoolertje]

Ja best wel, alsof iedereen die kan bruteforcen ook meteen weet hoe wat en waar hij een plain wachtwoord vandaan moet toveren...

Voor bruteforcen is er geen verschil tussen een hashed en plain tekst (hooguit voor de snelheid), maar voor hackers of publiekelijk uit te lezen logs (is geen hacken dunkt me) maakt het natuurlijk wel uit of het er hashed of plain tekst is staat...

Dus ja ook bij plain tekst opgeslagen wachtwoorden is een sterk wachtwoord veiliger dan een zwak wachtwoord.

[Reactie gewijzigd door watercoolertje op 24 juli 2024 22:11]

[Andreplusplus]

Jij weet heel goed de klok, maar niet zozeer de klepel...

[PommeFritz]

..... en wachtwoorden moet je niet versleuteld opslaan (encrypted) maar gehashed met een daarvoor geschikte key hash functie. Dit klinkt heel amateuristisch allemaal

[iceheart]

Oké, en wat denk je dat er gebeurt als je het nieuws en persbericht correct formuleert? Want hashing is geen bekende term bij de gemiddelde gebruiker; versleuteling dan weer wel.

Is het technisch gezien correct? Nee. Maar ook als je het technisch helemaal netjes uitvoert, is 'versleuteld' toch echt de term die je uiteindelijk aan je, veelal atechnische, eindgebruikers meedelen zult - dan snappen ze het tenminste (...of denken ze het te snappen, maar close enough).

[PommeFritz]

wel, je ziet nu wat er gebeurt als je het niet doet: onjuiste termen gebruiken voor een gevoelig onderwerp levert ook allemaal duscussie en verdachtmakingen op

[iceheart]

Het verschil daarin is dat je, als je wél de technische achtergrond hebt om te snappen wat er eigenlijk hoort te gebeuren, ook prima even kunt nadenken of de berichtgeving misschien ietsjes versimpeld is om bij de doelgroep aan te sluiten.

Die doelgroep mist meer de achtergrond om even jouw expertise te doorgronden, dan dat jij de achtergrond mist (geacht mag worden, allicht) om even na te denken wat voor de gemiddelde burger begrijpelijk is.

Niet de vakidioot uithangen, noemen we dat

[Andreplusplus]

Duscussie - is dat een discussie waar je te snel conclusies trekt?

[The Zep Man]

..... en wachtwoorden moet je niet versleuteld opslaan (encrypted) maar gehashed met een daarvoor geschikte key hash functie. Dit klinkt heel amateuristisch allemaal

Het is niet enkel een hash functie. Dat is een onderdeel. Wat je wilt is een key derivation function.

[.oisyn]

En een key derivation function valt op zichzelf ook weer onder de klasse van (cryptografische) hash functions.

[Donool]

De echte pro's gaan voor 4x ROT13

[Travelan]

Ik ben vooral benieuwd naar het bedrijf dat de PEN test heeft uitgevoerd. Die mag ook wel even aan de schandpaal, want voor hen is net net zo'n grote (of nog wel grotere) fout dan van ikwilhuren.nl.

[iceheart]

Ik zie in het nieuwsbericht zo snel niets over een pentest, dus of er uberhaupt adversarieel is getest weten we volgens mij niet eens zeker?

Daarnaast is deze fout ontstaan bij een servermigratie - logging aangezet om te zien of alles goed ging, logging vergeten uit te schakelen. Als die migratie na een eventuele pentest heeft plaatsgevonden zou de tester daarin weinig te verwijten zijn.

[Travelan]

"De fouten kwamen volgens de organisatie niet naar boven tijdens een pentest. "

Staat letterlijk in het artikel. Ergens laatste alinea.

[iceheart]

Fair enough, overheen gelezen. Blijft het zo dat de servermigratie heel goed na die test plaatsgevonden kan hebben (sterker nog, als die pentest deel van de oorspr. opzet was is dat vrijwel zeker het geval).

[Travelan]

Dan is het eigenlijk extra kwalijk dat ze nu juist naar de PEN test wijzen...Geen excuses voor....

[iceheart]

Gebrek aan grondig begrip bij een organisatie voor wie IT niet bepaald een kerncompetentie is, des te meer als dat gebrek aan begrip in het eigen voordeel werkt? Say it ain't so

[Travelan]

In mijn visie is IT in elk modern bedrijf een kerncompetentie (en anders ben je binnen 5 jaar irrelevant, uitzonderingen daargelaten natuurlijk). Zeker voor een bedrijf wat als handelsnaam een domeinnaam voert 😅

[kftnl]

Pentest heeft een specifieke scope en dat is niet altijd de live website. Daarnaast is het een momentopname, niet zo gezegd dat het probleem er ook was tijdens de pentest.

[Travelan]

En toch wordt gewezen naar de PEN test door ikwilhuren.nu. Dus blijkbaar hadden ze dat wel verwacht van de specialisten.

[Andreplusplus]

Tja, pentesten is een creatief proces en gelimiteerd door de beschikbare tijd.
Erwin Dirks had net even een andere creatieve inval en daarmee succes het gebrek van het systeem aan te tonen.

[Kiswum]

Ik mis alleen nog of er inmiddels ook een melding is gemaakt bij AP door de eigenaar van de site. Daarnaast is het informeren (resetten) van de gebruikers(wachtwoorden) de 2e belangrijke stap.

[Reactie gewijzigd door Kiswum op 24 juli 2024 22:11]

[TijsZonderH]

Heb ik erbij gezet, hebben ze gedaan ja.

[Martijn02]

Is er melding gemaakt bij het AP? Zijn de getroffen gebruikers persoonlijk geïnformeerd?

De toon van het artikel lijkt te suggereren dat MVGM denkt dat het met het weghalen van de log klaar is.

Ook het zinnetje "Dat wordt voortaan versleuteld opgeslagen" roept vragen op. Was dat (behalve in de debug log) niet het geval dan?

[erics86]

Super mooi dat Dhr Erwin Dirks dit gemeld heeft en dat de wereld weer een stukje veiliger is geworden! Ik hoop dat bedrijven die met persoonsgegevens werken leren van dit artikel en zichzelf regelmatig laten controleren op beveiligingslekken.
Want door ontwikkeling van een applicatie kan nieuwe bugs/lekken introduceren.