Contactlenzenwebshop Lensdeal waarschuwt klanten voor gestolen wachtwoorden

De gegevens van zo'n 115.000 klanten van Lensdeal zijn bij een datalek gestolen en op een hackersforum geplaatst. Daarbij zijn ook wachtwoorden gestolen. Het bedrijf doet nog onderzoek naar de omvang, maar zegt dat het gaat om een oude testdatabase.

Lensdeal datalekLensdeal.nl, een webwinkel voor contactlenzen en accessoires, waarschuwt klanten in een e-mail dat hun gegevens mogelijk zijn uitgelekt. Ook meerdere tweakers hebben die e-mail ontvangen. "Helaas hebben wij vernomen dat een oudere database van een jaar geleden met onze klantgegevens is gestolen", schrijft het bedrijf. Daarbij zijn in ieder geval 'adressen en e-mailadressen gestolen'. Om welke gegevens het precies gaat, schrijft Lensdeal niet, maar Cybercrime Info heeft een screenshot gemaakt van de gegevens die op Breach Forums worden aangeboden. Tweakers heeft de dataset zelf nog niet kunnen verifiëren.

In dat screenshot is te zien dat de gegevens van 115.096 klanten zijn uitgelekt. Veel van die gegevens zijn websitegegevens zoals gebruikers- en sessie-ID's, maar er zijn ook namen, e-mailadressen en geboortedatums gestolen. "Uw financiële gegevens zijn veilig", schrijft Lensdeal. Betalingen werden door een externe partij afgehandeld en niet opgeslagen door de webshop zelf.

Wel staat in het screenshot dat er wachtwoorden zouden zijn gestolen. Het gaat dan om de entry's passwd en last_passwd_gen. Lensdeal erkent dat zelf ook. "Uw wachtwoord is en was beveiligd en is door derden niet te lezen, maar wij adviseren u wel om zo spoedig mogelijk uw wachtwoord te wijzigen." Het is niet bekend wat de webwinkel bedoelt met 'beveiligd'; zo is niet duidelijk welk hashalgoritme er gebruikt is. Het bedrijf doet daarnaar nog onderzoek. "We zijn samen met de politie en Autoriteit Persoonsgegevens bezig om te inventariseren wat er is gebeurd en overal is melding gemaakt", zegt het bedrijf in een reactie aan Tweakers. "Het gaat in ieder geval om een oude testdatabase die gestolen is. De precieze toedracht is nog niet bekend. Dat wordt nu uitgezocht."

Door Tijs Hofmans

Nieuwscoördinator

03-04-2025 • 11:28

55

Submitter: basmevissen

Reacties (55)

55
54
27
5
0
16
Wijzig sortering
Ik ontving dinsdag een Dark Web Monitor-alert van NordVPN met daarin de mededeling dat mijn gegevens mogelijk gelekt zijn. Ik heb daarop een screenshot van de mail doorgestuurd naar Lensdeal en woensdagnacht ontving ik bericht van Lensdeal.

Naar aanleiding van dat bericht heb ik aanvullende vragen gesteld:
  • welke gegevens zijn er gelekt?
  • wanneer en hoe het lek is ontdekt?
  • wanneer heeft Lensdeal besloten het lek te melden bij de AP?
  • wanneer heeft Lensdeal besloten het lek te melden bij de betrokkenen?
Al vrij snel kreeg ik een reactie:
Lensdeal is door het Ministerie van Economische Zaken telefonisch geïnformeerd en heeft direct daarna melding gemaakt bij de AP én aangifte gedaan bij de politie. Het betreft een database uit februari 2024, welke gestolen is uit een testomgeving omdat het 'door menselijk falen op een verkeerde locatie is geplaatst'. Volgens Lensdeal bevat de database 'data wat door de klant zelf in de webshop is ingevuld' minus betaalgegevens.

Gelukkig reageert Lensdeal erg transparant. Ja, Lensdeal had hier zaken anders kunnen/moeten regelen voor wat betreft het vullen van de testomgeving met livedata, maar op basis van het mailverkeer wat ik heb gehad maak ik op dat men erg geschrokken is.

[Reactie gewijzigd door Burton op 3 april 2025 13:25]

AuteurTijsZonderH Nieuwscoördinator @Burton3 april 2025 13:40
Gelukkig reageert Lensdeal erg transparant
Eens, ook in communicatie richting ons. Wel erkennen dat er iets fout is gegaan, maar ook onderzoek (laten) uitvoeren. Ik snap dat ze niks willen zeggen maar ze reageerden hier snel op.
Lol, door EZ gebeld worden. Anyway, goed om te lezen dat de betreffende instantie actief naar buiten treed
AuteurTijsZonderH Nieuwscoördinator @terror-oehoe3 april 2025 20:22
Ik vermoed dat ze daar het Digital Trust Center mee bedoelen, die letten hierop. DTC is onderdeel van het ministerie.
Lekker bezig, klant data in een testdatabase is altijd handig!
Niet dat ik het goed praat, het zou niet moeten gebeuren, maar om eens een ander perspectief te bieden:

In je testomgeving wil je zo realistisch mogelijke gegevens. Nou kun je best zelf wat invullen en misschien zelf wel goed je best doen, maar echt klantgedrag gaan je nooit lukken. Immers, j hebt het systeem zelf ontworpen, je weet al waar je moet klikken. Het komt niet eens in je op om X te doen voordat je Y doet.

Dus krijg je een dataset die niet dicht bij je live situatie zit.
Dus je krijgt issues op live omdat je die niet eerder had kunnen vinden.
Dus nu heb je de keuze:
1. Helemaal correct random/gegenereerde data, maar grotere kans dat je echte klanten bugs ondervinden
2. Een kopie van live met wat trucjes om de data veilig te maken

Optie 2 wordt best wel vaak gedaan, ook door grotere bedrijven, het is gewoon een afweging voor 'the lesser evil'. En in 99% van de tijd kom je weg met optie 2 en in 1% van de tijd redt je het nieuws.

In dit geval zijn ze vergeten alle wachtwoord(hashes) te updaten naar die van 'password', dan had nooit iemand hier achter gekomen en is 5min werk om op te zetten. Hopelijk leert de rest hiervan :)

----

Grapje dat ik leuk vind welke mn punt 'bewijst':
Een Programmeur heeft een Bar geprogrammeerd en de Tester gaat het testen:
- Tester bestelt 1 bier -> krijgt 1 bier -> pass
- Tester bestelt 10000000 bier -> "aantal teveel melding" -> pass
- Tester bestelt -5 bier -> "moet meer dan 0 zijn melding" -> pass
- Tester bestelt driehoek bier -> "Dat is geen aantal melding" -> pass

De Tester geeft groen licht en de Bar gaat live!
De eerste klant komt binnen en vraag waar het toilet is.

(Thanks @P_Tingen: https://dev.to/idanarye/comment/8nfo)


offtopic:
Edit voor de -1 stemmers: het feit dat mijn voorbeeld mogelijk 'ongewenste gewoontes' zijn, betekent niet dat mijn comment hier dat ook is he? :9 Ik probeer slechts een situatie te schetsen zodat mensen zouden kunnen inzien waarom het mogelijkerwijs toch gedaan is, ondanks de puristische insteek van "helemaal niet doen".

[Reactie gewijzigd door Martijn.C.V op 3 april 2025 16:10]

Optie 2 wordt best wel vaak gedaan, ook door grotere bedrijven, het is gewoon een afweging voor 'the lesser evil'. En in 99% van de tijd kom je weg met optie 2 en in 1% van de tijd redt je het nieuws.
De impact van een foutje is echter gelijk vele malen groter.

Hoevaak komt het voor dat een fout hem daadwerkelijk zit in de invoer van een e-mail adres? Hoe vaak komt het voor dat een bug daadwerkelijk zit in een voor of achternaam?

Toevallig Best vaak vanwege cyrillische karakters enzo, maar dat kun je gewoon testen, ook met generated spul. Er is geen enkele reden ooit om gebruik te maken van productiedata voor tests. Er is wel een reden om testdata te generen gebaseerd op productie data.

Al was het maar om bijvoorbeeld een grote klant na te kunnen bootsen. Iemand die 5000 van jouw dingen wil ipv de gebruikelijke ~1-100.

Ik heb dit zelf bij een klant meegemaakt dat de grote van hun klant zorgde voor een loop die per vestiging groter en groter werd. Zelfde soort probleem als wat GTAV had in het laadscherm. Voor ieder item alle andere items weer langs.
Ja, het risico van de 1% :)

En je hebt idd niet echt mailadressen en namen nodig, maar wel de interacties tussen de Users en andere onderdelen van je site, zoals log en wachtwoordresets en ... en ..., dat gebeurd op een manier dat je nooit met zelfgemaakte testdata kunt doen.

Maar goed anonimiseren is IMO dan wel een harde eis ja, maar helaas deelt niet iedereen alle principes en blijven hangen in een "Ja, maar sha1 werkt lekker makkelijk" :+
dat gebeurd op een manier dat je nooit met zelfgemaakte testdata kunt doen.
Ik zie niet in hoe dat niet kan, maar hoor graag een voorbeeld van je. Ik denk dat we, zeker met huidige tooling, echt wel dat soort interacties kunnen nabootsen. Tools als playwright enzo.

En als je echt een randomisatie dingetje in de interactie wil, kun je het ook met AI tooling doen. Collega had daar laatst uren schrijven mee geautomatiseerd. Leuke exercitie en wel degelijk nuttig op die manier.


Verder heb je voor dat soort dingen (als het echt niet anders kan) ook realtime user monitoring. Als er dan dingen fout lopen krijg je direct een seintje je monitoring systeem.
Je kunt prima klant data gebruiken, dat is ook niet het euvel. Maar anonimiseer de boel dan. Je hoeft er toch geen echte namen, wachtwoord hashes, woon en email adressen in te zetten.

[Reactie gewijzigd door orvintax op 3 april 2025 13:32]

"Tester besteld" -> Error, geen correct Nederlands -> Fail
Je vergeet nog te melden wat er daarna gebeurt, want vervolgens vliegt de hele bar in de brand waarbij iedereen om het leven komt
https://dev.to/idanarye/comment/8nfo
Inderdaad, hoe halen ze het in hun hoofd.
Hier zou een boete van de AP op moeten staan.
Dit is de echte fout. Je kan hier prima zeggen dat het datalek op de datum van het maken van de kopie is, niet toen nu het probleem als dan niet door een fout in beveiligingslogica ontdekt is.

Security 100.00% goed krijgen is een utopie. Security 99.999% goed krijgen gaat je werkgever ook niet betalen. Goede nieuws is dat genoeg maatregelen de impact of kans wel drastisch kunnen verkleinen. In dit geval is De Maatregel met beste effect, om nooit die kopie te maken. Nee, echt nooit. Als developer heb je echt nooit echte namen en passwordhashes nodig.
Data die er niet is, hoe je ook niet te beveiligen. :)

Elk compliance of certificering (GDPR, ISO, SOC, ISAE etc) gaat heel hard op dit punt. Sommige controlevragen kan je nog mee wegkomen met dat je nog gaat verbeteren. Productiedata buiten productie echter -> Failed audit.

Zie ook mijn andere reactie, over password managers. Nogmaals,
veel maatregelen zijn duur of specialistisch om goed te krijgen. Productiedata discipline en password managers zijn een fijne uitzondering; niet duur en bij consistent gebruik ook eenvoudig.

[Reactie gewijzigd door Voutloos op 3 april 2025 13:27]

niks anonimiseren, waarom zou je? :+
Het zou verplicht moeten worden om aan te geven hoe wachtwoorden worden bewaard. Er zit nogal wat verschil tussen unsalted md5 (of zelfs encryptie) en 13 rondes Bcrypt...
AuteurTijsZonderH Nieuwscoördinator @peize93 april 2025 12:40
Dit is een vraag die wij standaard stellen aan een partij als er wachtwoorden zijn gelekt. Dat staat zo ook in onze richtlijnen voor securitynieuws. Lensdeal heeft daar alleen nu geen antwoord op gegeven en zegt dat het onderzoek nog loopt.
Dacht ik al, maar het zou geqoon bekend gemaakt moeten worden, het is immers een belangrijk onderdeel van de lek.
AuteurTijsZonderH Nieuwscoördinator @peize93 april 2025 13:31
Ik denk dat ik het daarmee eens ben, maar weet uit ervaring ook dat het eerder uitzondering dan regel is dat slachtoffers überhaupt weten wat een hash is, laat staan welk algoritme ze gebruiken. Case in point, ik lees doorgaans alleen dat wachtwoorden 'versleuteld' zijn, wat natuurlijk ook al niet klopt.
*wat hopelijk niet klopt. Adobe heeft geloof ik ooit een lek gehad met encrypted wachtwoorden, niet hashed. https://www.csoonline.com...pted-not-hashed.html/amp/ 150 miljoen encrypted passwords :+

Je mag er van uit gaan, maar het gaat ook echt (te) vaak mis. Ik hoop dat ze het goed hebben gedaan.

[Reactie gewijzigd door peize9 op 3 april 2025 19:00]

AuteurTijsZonderH Nieuwscoördinator @peize93 april 2025 13:38
Ja inderdaad, wat waarschijnlijk niet klopt. Uit de context maak ik dan vaak wel op dat ze hashed bedoelen, vaak schuif ik dat af op onwetendheid.
Ik ga er zomaar vanuit dat dit stuk wordt uitbesteed aan een derde partij, aan wie deze vraag is gesteld. Mogelijk is deze wat minder transparant naar Lensdeal toe.
Ik heb het ze ook gevraagd (ik zat in het lek) en kreeg terug:
Wij hopen op uw begrip omdat dit voor ons/mij de eerste keer is dat wij zoiets meemaken en de beveiling van uw gegevens erg serieus nemen, dat gezegd wordt er wel door mensen gewerkt en als zodanig ook wel eens een fout gemaakt. Wij van Lensdeal zijn nu 10 jaar bezig om een goede naam op te bouwen en betreuren dat door toedoen van derden wij nu negatief nieuws moeten verspreiden.
Voor wat betreft uw technische vragen daar heb ik helaas geen antwoord op.
Klantdata in een testdatabase is een systematische fout, niet een menselijke... Je neemt de veiligheid van gegevens dan zeker niet serieus.
Denk niet dat je de methode op tafel wil leggen, dan zou je een rainbowtabel kunnen maken op die methode.
Bij een goede hashing+salting is dat simpelweg onmogelijk.
Als het bekend maken van de methode een probleem is, dan is je methode verkeerd.
Het hele punt van cryptografische algoritmes is dat het weten van de implementatie geen invloed zou moeten hebben in het kunnen kraken. Uiteraard maakt het het iets makkelijker, maar de tijd om 1 password te kraken is nog steeds “lang”.
ik ben zo blij met 1password en of keychain!
Anoniem: 278217 @nova3 april 2025 11:46
Want dat voorkomt dat een website zijn database gehacked/gestolen word? xD
Hoe sterk je wachtwoord ook is, dat staat hier volledig los van heur.
Zonder passwordmanager zal je doorgaans zwakkere wachtwoorden gebruiken. Het lijkt er op dat de hashes van wachtwoorden gelekt zijn en dat is voor korte/slechte/herbruikte wachtwoorden wél alsnog problematisch.

Daarnaast zal je met een manager en goed gebruik ook geen wachtwoorden herbruiken.

Last but not least, ook kunnen passwords managers waarschuwen voor een gemeld lek, en soms helpen met roteren.

In theorie kan veel van deze punten ook zonder manager, maar mensen zijn dusdanig slecht in random waardes maken / ezelbruggetjes / herbruik dat dit anno nu niet meer met droge ogen gezegd kan worden.

Zoals anderen ook zeggen impact dus, maar bij deze de onderbouwing. ;)

[Reactie gewijzigd door Voutloos op 3 april 2025 11:56]

Ja een paar jaar terug overgestapt op Bitwarden.
Ik was 1 van de velen die 1 wachwoord voor zo'n beetje alles had.
Soms kom ik nog een account tegen waarvan ik het wachtwoord ben vergeten te veranderen.
Laatst kreeg ik daar dan nog een melding dat er iemand daar probeerde in te loggen.
Gelukkig moest je dit accepteren via je mail.
Misschien de vrouw thuis ook maar een keer overtuigen om een wachtwoordmanager te gebruiken.
Die gebruikt dus ook veelal variaties van 2 wachtwoorden.
De realiteit is helaas dat er datalekken zijn. Voor de meeste mensen is de frequentie van relevante lekken misschien eerder jaarlijks dan nooit. Niet fijn of goed, wel de realiteit.

Als IT-er moet je elke kans aangrijpen om een passwordmanager aan te raden. Het is niet offtopic, maar zelfs al was het zo, moet je geen ruimte tot twijfel laten over het nut, voor de doorsnee gebruiker die dit nieuws leest.
Dan is er alleen een wachtwoord van 1 website gestolen, en kan dat wachtwoord nergens anders gebruikt worden. Er zijn veel mensen die wachtwoorden hergebruiken, omdat ze het anders nooit kunnen onthouden voor al die websites. Dus je verkleint de aanvalsvector aanzienlijk op deze manier.
Dat zorgt ervoor dat het voor jou helemaal geen impact heeft omdat je dan voor ieder website een uniek wachtwoord hebt.
Je wachtwoorden niet recyclen is oplossing nummer 1 hiertegen ja...
Met een uniek wachtwoord voor elke login zijn dit soort lekken een non-issue.

[Reactie gewijzigd door Polderviking op 3 april 2025 13:28]

Ik met goede ogen. ;)
Ik zou eigenlijk een Manager willen die automatisch invult op PC en mijn iPhone, zal eens in 1 password duiken
Ik ga er induiken, dankjewel!
Ik krijg alleen maar vragen adhv deze tekst:
- waar zwierdf zo'n database dan rond?
- een testdatabse met klantgegevens, niet geanonimiseerd en geen passwords gescrubbed?
- gaan ze klanten nog informeren dat ze onderdeel hiervan zijn geweest?
1 en 2 lijken me interne aangelegenheden. Dit is oerstom natuurlijk (dat zullen ze zelf achteraf ook wel beseffen), maar voor het publiek is dit geen kritische informatie.

En puntje 3: dat doen ze toch dmv de email waar dit artikel over gaat?

Als ik het zo bekijk is de reactie best netjes. Bevat de juiste informatie en de juiste adviezen. Dat ze zo stom geweest zijn dit in de eerste plaats te laten gebeuren kun je natuurlijk wat van vinden, maar gedane zaken nemen geen keer...
Dit is geen interne aangelegenheid. Volgens GDPR ligt de lat heel hoog om persoonsgegevens in een testdatase te gebruiken. Zelfs pseudonimiseren, anonomiseren of scramblen is niet altijd voldoende.
Opmerkingen zoals "We zijn samen met de politie en Autoriteit Persoonsgegevens bezig om te inventariseren wat er is gebeurd en overal is melding gemaakt" mogen wat mij betreft wel van wat duiding worden voorzien in plaats van het zo over te nemen. Voor zover ik weet gaat de AP niet samen met verwerkingsverantwoordelijken incidenten afhandelen. Wat hier het meest waarschijnlijk aan de hand is is dat de het formulier hebben ingevuld om het datalek te melden bij de AP. En als dat formulier dusdanig is ingevuld dat de AP het nodig vindt om er tijd aan te besteden kan het zijn dat de AP actief toezicht houdt door vragen te stellen. Ik heb nog nooit meegemaakt dat een dergelijke mededeling over "samen" met de AP in zo'n context een redelijke weergave is van wat er aan de hand is.
AuteurTijsZonderH Nieuwscoördinator @Floort3 april 2025 13:37
Hier ben ik mee eens. Dat was in dit geval een ingecalculeerde quote, ze lieten namelijk al meteen vrij duidelijk weten dat ze niks wilden vertellen en dat we beter nog eens contact konden opnemen als het onderzoek voorbij was. Mijn ervaring is dan dat het geen zin heeft om door te vragen, en zeker als je wel wil publiceren ga ik dan niet nog eens een halve dag wachten op een antwoord via mail. Dan hou ik het bij de quote die ze geven.

Ik had hier achteraf wel bij kunnen zetten dat een melding bij de AP (meestal) verplicht is of in ieder geval standaard praktijk. Dat doe ik normaal wel, maar ik had er nu niet bij stilgestaan.
Ik weet dat je het misschien net niet kan maken, maar ik had waarschijnlijk erachter omschreven dat als de AP actief bezig is met een datalekmelding dat dat meestal betekent dat het heel ernstig is of dat de melding niet in orde is.

De afweging om niet te wachten op antwoorden die waarschijnlijk niet gaan komen als je vervolgvragen stelt snap ik heel goed.
AuteurTijsZonderH Nieuwscoördinator @Floort3 april 2025 14:11
als de AP actief bezig is met een datalekmelding
Het is de vraag of dat echt zo is. Het kan heel goed zijn dat een relatief klein bedrijf als dit een AP-formulier invult, ze dat al snel kunnen interpreteren als 'de AP is ermee bezig'.
Zeggen dat je samen met de AP bezig bent om te inventariseren wat er is gebeurd als je alleen een online formulier bij de AP hebt ingevuld zou ik gewoon een leugen noemen. Dat wil niet zeggen dat je suggestie over wat er aan de hand zou kunnen zijn onredelijk is. Integendeel: in mijn ervaring is er een redelijke kans dat je gelijk hebt. Ik krijg gewoon onredelijk de kriebels van de inhoud van de quote.
Ik vind het eigenlijk ook maf dat jan en alleman die als IT'er ergens wordt aangenomen toegang krijgt tot de hele productiedatabase. Lijkt mij net als private keys dat alleen maar een select groepje daar toegang tot heeft en de rest krijgt alleen maar een sample test database om mee te werken.

9 van de 10 keer zijn data lekken gewoon inside jobs evenals met sim swapping.

Uit coronatijd is duidelijk naar voren gekomen dat er heel wat mensen illegale acties willen ondernemen voor een paar honderd euro.
Lensdeal heeft vast wel alles gedaan wat ze konden om hun beveiliging op orde te houden. Toch is het altijd goed om je online veiligheid zelf in de gaten te houden. Misschien tijd om bij Specsavers langs te gaan voor een scherpere focus, zowel op je lenzen als op je wachtwoorden.
Sorry to burst your bubble, maar veel bedrijven interesseert dit geen klap. Het moet zo makkelijk en goedkoop mogelijk, de gevolgen worden afgekocht of onder het tapijt gemoffeld.
Niet als je een productiedatabase als testdatabase gebruikt wat ik lijk op te maken uit dit artikel.
Waar gaat zo'n testdatabase allemaal zwerven? Bij een developer op zijn laptop bv.
Dit zag ik niet aankomen.
Vreemd, ik heb ook een account maar de mail niet gehad. Zit ik dan wel of niet bij de leak? Ik heb redelijk recent nog een bestelling gedaan.

Op dit item kan niet meer gereageerd worden.