Datalek bij maaltijdbezorger Foodora treft 50.000 Nederlandse klanten

De gegevens van duizenden klanten van maaltijdbezorgdienst Foodora zijn buitgemaakt bij een datalek. Het gaat behalve om namen en adressen ook om telefoonnummers en de bestelgeschiedenis. Onder de slachtoffers bevinden zich zo'n 50.000 Nederlanders.

Foodora was tot 2018 in Nederland actief, maar inmiddels niet meer. De gegevens gaan terug tot 2016, bevestigt het bedrijf aan Data Breach Today. In totaal zijn de gegevens van 727.000 accounts gestolen. Daaronder zijn 50.000 Nederlanders, zegt hacker Rickey Gevers tegen BNR.

Bij de hack zijn namen en adressen gestolen, en telefoonnummers als die aan het account gekoppeld waren. Daarnaast is de bestelgeschiedenis in te zien, inclusief de notities die een klant bij een bezorging plaatst. Daarnaast zaten er locatiegegevens bij bestellingen.

Bij de gegevens zijn ook gehashte wachtwoorden buitgemaakt. Volgens Rickey Gevers gaat het bij Nederlandse slachtoffers in 22.000 gevallen om een bcrypt-hash. In de database zaten ook wachtwoorden met de zwakke MD5-hash, zegt Troy Hunt van Have I Been Pwned, al is niet bekend om hoeveel het daarbij gaat.

Een database met de gestolen gegevens werd sinds 19 mei op hackerforums aangeboden. De oudste data in de database lijkt uit augustus 2015 te komen en de recentste uit april 2016. In totaal zijn 600.000 unieke e-mailadressen gestolen van gebruikers uit veertien landen. Die waren verdeeld in sql-databases die per land verdeeld zijn.

Het moederbedrijf van Foodora, Delivery Hero, sloot in 2018 de deuren in Nederland. Het bedrijf kon geen koper vinden voor de Nederlandse activiteiten. De Duitse activiteiten werden doorverkocht aan het Nederlandse TakeAway.

Reacties (64)

Dit is weer een prima voorbeeld van waarom dataminimalisatie zo belangrijk is. Iedere keer dat je ergens je gegevens achter laat groeit de kans dat ze vroeg of laat uitlekken. Je kan nu onmogelijk voorspellen welke bedrijven de komende 20 jaar goed op je data passen en welke je data verkopen of laten lekken.
Natuurlijk mogen ze die data eigenlijk niet zo lang bewaren, maar dat kun je zelf eigenlijk niet controleren, dat is net het punt.

De beste manier om te voorkomen dat je data lekt is zorgen dat er niks is om te lekken.

Ik zou graag een systeem zien waarbij je verwijzingen naar data kan geven, in plaats van de data zelf.

Als je bijvoorbeeld bij een webshop bestelt dan hoeft de webshop eigenlijk niet te weten hoe je heet of waar je woont. Het enige wat de webshop echt moet weten is a. dat er betaald is en b. welke postbode het pakket komt ophalen. De postbode moet dan genoeg informatie krijgen om het pakket bij de klant te krijgen.

[Reactie gewijzigd door CAPSLOCK2000 op 16 juni 2020 14:36]

Voor de postbode is een afleveradres wel handig.

Ik vind de webshops wel fijn waar je zowel met als zonder account kunt bestellen. Zonder account betekent natuurlijk niet per se dat je gegevens nergens bekend zijn, maar met account weet je zeker dat het er wel opgeslagen is.

Ik ga je even uit je droom helpen... Het verschil tussen wel / geen account binnen webshops is nihil.

Kijk je bijvoorbeeld naar een pakket als Magento, toch 1 van de meest populaire e-commerce pakketten op de markt, dan wordt er onderaan de streep net zoveel data opgeslagen als je met of zonder account bestelt. Het enige verschil is dat je misschien geen wachtwoord hebt opgeslagen, maar dat is is slechts een detail. Magento stuurt vervolgens haar gegevens door naar tenminste 1 en vaak meerdere partijen. Het pakket moet bijvoorbeeld immers verzonden worden via PostNL, waarbij de kans groot is dat je e-mailadres of telefoonnummer ook meegezonden wordt.

En dan heb ik het nog niet gehad over het boekhoudpakket, een eventueel warehouse magenement systeem, een dropshipment partner of een extern verkoopkanaal zoals Bol.com. Allemaal plekken waar mogelijke veiligheidslekken kunnen zijn.

Of over de eisen van o.a. de belastingdienst qua facturatie...

het belangrijkste gedeelte is toch wel het wachtwoord en eventueel kreditkaart gegevens, daar kunnen immers iets mee, vooral omdat veel mensen meestal het zelfde passwoord gebruiken. dat wat ik eet of gekocht heb is niet zo belangrijk voor de crimineeltjes. e-mail adres en telefoon nummer is ook een mindere zorg.

Voor het afhandelen van creditcardgegevens moet je al jaren PCI Compliant zijn. Kortweg: je moet je datacenter in een bunker hebben, dikke deur ervoor, bewakers ervoor, etc, etc. Denk niet dat Foodora dat ooit gehad heeft.

Wachtwoord is interessant, maar goed, daar heb je vaak ook andere bronnen voor.

Voor de postbode is een afleveradres wel handig.

Precies, de postbode moet weten waar het pakketje naar toe moet. Die informatie hoeft niet aan de website te worden doorgegeven.

En HOE krijgt de postbode die data dan als de webshop geen adreslabel erop plakt?

Dat is het punt, die informatie moet via een apart kanaal gaan. Op het adreslabel staat een anoniem nummer dat de postbode kan gebruiken om het echte adres op te zoeken.

Er zijn verschillende systemen denkbaar. Je zou een stuk van het formulier dat de klant invult direct naar de postbode kunnen sturen in plaats van naar de webshop. De postbode geeft dan een track&trace-achtige code terug die de webshop op het pakket moet printen om het te laten bezorgen.

Zelf heb ik een tijd het omgekeerde gedaan*. Ik maakte gebruik van een bedrijfje dat mijn post voor me aan nam en achter me aan bracht. Als ik iets bestelde dan vulde ik niet mijn eigen naam en adres in, maar gaf ik het adres van dat bedrijf op en mijn klantnummer.

* Dat was handig omdat ik overdag nooit thuis was en het lokale postkantoor 's avonds gesloten is.

[Reactie gewijzigd door CAPSLOCK2000 op 16 juni 2020 13:41]

Ik vraag al jaren om een virtueel adressysteem voor particulieren bijna vergelijkbaar met de postbus voor bedrijven. Bij jouw postbode vraag je een virtueel adres aan: Tweakerstraat 123-HS --> 8cef5bf97ec227c954c169c3aeb09bb4 (dit geval gewoon een MD5 hash, maar moet een random sequence voorstellen).

Op zich is een hash database nog niet eens zo gek want dan heb je minder kans op collisions dan een puur random database. Voor meerdere unieke adressen salts toevoegen en je kan er zoveel aanmaken als je wil welke allemaal bij het postkantoor herleiden naar jouw huisadres. Bij het sorteercentrum plak je er een leesbaar adres op en de postbode heeft er weinig last van. Beetje omgekeerde volgorde en wellicht is er een beter systeem maar zo heel moeilijk hoeft dit toch niet te zijn?

Een systeem als dit zou helemaal makkelijk toepasbaar moeten zijn voor een e-mailadres waar we nu stuntelen met punten en plus tekens die veel te makkelijk te zoeken en vervangen zijn kan je op deze wijze per account een volledig onherkenbaar adres opgeven waarbij de mail altijd weer bij jou binnen komt.

Edit: even gezocht en betreft e-mail adressen lijkt firefox private relay hier het meest toepasbaar te zijn. Helaas nog invite-only en experimental.

[Reactie gewijzigd door Tadsz op 16 juni 2020 14:46]

Wat je hier beschrijft heeft een analogie in de doorstuur service bij verhuizingen: het ene adres staat op de post maar effectief wordt dat in het postsorteercentrum omgezet naar het definitieve echte adres.
Nadeel van jou methode is dat waar je eerst veel point-of-failures (webwinkels) had met een subset van de adressen je nu een single point-of-failure ('de post') hebt met *alle* adressen.

Het is inderdaad een single point of failure en mogelijk target voor mensen die uiteindelijk de database met unieke adressen wil hebben om er toch achter te komen waar je echt woont. Maar is dat dan gevaarlijker dan hoe wij nu gewoon overal dit gegeven verspreiden?

Sterker nog, een single point of failure is hier juist makkelijker te beheren omdat je je security één keer goed moet doen. Een beetje als je webservices achter een reverse proxy zetten in plaats van al je poorten open te gooien.

Het wordt wel lastig om van diverse leveranciers post te ontvangen en je maakt concurrentie op pakketbezorging ook een stuk moeilijker tenzij hier een centraal punt voor opstaat. Daar komen ook een hoop vragen bij kijken zoals wie kwalificeert voor een bezorgservice en hoe die gegevens verstrekken.

Dus iedere keer als jij wat besteld stuur je je postcode en betaling naar het bedrijf, en je adresgegevens naar de postbode met de mededeling dat je een pakketje verwacht van bedrijf x? Lijkt mij nogal omslachtig, nog los van de vraag of dat dat daadwerkelijk iets toevoegt. Natuurlijk, de webshop heeft alleen jouw postcode, maar aan de hand van de betaling kunnen ze andere gegevens (zoals jouw naam) ook achterhalen. Dan hebben ze naam+postcode en is het dus een peulenschil om het adres te achterhalen.

Ik snap op zich wel wat je zegt, en ben het er ook mee eens: er worden te vaak te veel gegevens gevraagd voor een simpele bestelling, bijvoorbeeld webshops die een telefoonnummer vereisen. Maar deze oplossing zie ik niet zo 1-2-3 werken.

helaas heb ik zelf geen betere oplossing voor handen

Ongeveer.

Ten eerste stuur je niet letterlijk je postcode maar een anoniem nummer dat tijdelijk of eenmalig aan jouw adres is gekoppeld. Alleen de postbode kan die koppeling maken. Dat zou zelfs getrapt kunnen. De eerste postbode hoeft alleen te weten naar welke stad het moet, alleen de postbode die het pakket afgeeft hoeft het exacte adres te hebben.
We kunnen het er nog over hebben of de postbode ook je naam nodig heeft of dat je adres wel genoeg is.

Ten tweede stuur je niet je naam en rekeningnummer naar de webshop, maar alleen naar je bank (of een tussenpersoon). De bank geeft dan aan de webshop door dat bestelling 1234 is betaald. De webshop weet niet wie er heeft betaald of op welke manier, alleen dat de bank zegt dat het geld binnen is.

Uiteraard moet het systeem zo worden opgezet dat de gebruiker niks extra hoeft te doen.

Orders worden ook gewoon opgeslagen met alle ingevoerde gegevens erin, en het gaat het systeem in van de afleverende partij. Als je online spullen koopt dan strooi je persoonlijke gegevens rond, je doet er niets aan.

Sterker - ik vermoed dat als je een account maakt je data alsnog per order gedupliceerd wordt zodat het aanpassen van je account gegevens niets verandert aan de order historie.

Om even op je tweede alinea in te gaan, wordt hiervoor een methode genaamd normalisatie ingezet. Dit houd in jouw voorbeeld in dat er drie tabellen komen (+ nog veel meer, maar nu niet van toepassing):

• Klant
• KlantInfo
• Bestelling

Een Klant kan meerdere entries hebben in KlantInfo (one to many)
Een Bestelling verwijst naar één KlantInfo (met NAW-gegevens, email, enz.), maar tegelijk kunnen meerdere bestellingen naar dezelfde KlantInfo verwijzen.

Op die manier kan je als klant je adres aanpassen zonder een nieuw profiel aan te maken, en blijven je oude bestellingen netjes op je oude adres staan. Aan de andere kant slaat een webshop in dat geval nooit meermaals hetzelfde gegeven voor dezelfde klant op.

[Reactie gewijzigd door MacBreQ op 16 juni 2020 13:34]

Er zal niets gedupliceerd worden, het zal alleen gelinkt worden. Je hebt meerdere tabellen, bijvoorbeeld 1 voor orders, en 1 voor klanten, en hier dan een optionele "one to many" relatie tussen (1 klant met meerdere orders). Daarmee kan een order zowel op zichzelf staan, als gekoppeld aan een klant/account.
Het kan ook met een tussentabel, maar dan wordt het in principe een "many to many" relatie.

Bedrijven moeten bepaalde gegevens van klanten bewaren voor de bedrijfsadministratie en als je geen adres opgeeft bij een eten-bestelapp maak je het de bezorger wel erg lastig.

PostNL zou systeem kunnen bouwen zoals jij dat beschrijft, waar een bedrijf puur een token print op een sticker met jouw accountgegevens erop dat PostNL kan gebruiken om je pakket te bezorgen. Een soort iDeal of Paypal of Stripe maar dan voor adressen.

Het zou alleen nogal nutteloos zijn, aangezien de belastingdienst je verplicht voor minstens 7 jaar lang alle naam- en adresgegevens van al je klanten te bewaren (want die informatie moet op je facturen). Tot die wet gewijzigd is, kun je als bedrijf niet zo werken helaas.

Bedrijven moeten bepaalde gegevens van klanten bewaren voor de bedrijfsadministratie e
<knip>
Tot die wet gewijzigd is, kun je als bedrijf niet zo werken helaas.

Dat klopt helemaal, wat ik voorstel is niet zomaar eenzijdig uit te rollen. Als we zo iets willen zullen we dat op verschillende manieren moeten invoeren, inclusief wettelijke aanpassingen die dat mogelijk maken.

als je geen adres opgeeft bij een eten-bestelapp maak je het de bezorger wel erg lastig.

Dat is dan ook niet mijn bedoeling. De bezorger krijgt het adres wel, maar het restaurant niet.

[Reactie gewijzigd door CAPSLOCK2000 op 16 juni 2020 14:35]

Je weet dat meestal de bezorger in loondienst van het restaurant zit?

Dan werkt het uiteraard niet, mijn voorstel heeft inderdaad z'n beperkingen. Volgens mij wordt de bezorging tegenwoordig steeds vaker gedaan door externe bedrijven als Uber Eats, maar daar kan ik me in vergissen.

Mijn doel is om het verspreiden van informatie zo veel mogelijk te beperken. Bij een bedrijf/restaurant dat alles zelf doet is dat probleem toch al kleiner dan wanneer zowel het restaurant als de bezorger het adres nodig hebben.

Je voorstel klinkt logisch vanuit de gedachte dat alleen personen die met de data te maken hebben die data zouden moeten hebben zolang het nodig is. Vooral bij gegevens die iets over personen zegt. Daar is al wetgeving voor: de avg. Een nadeel is dat minimalisatie niet gelijk staat aan versimpelen. Het is makkelijk stellen dat er bijvoorbeeld meer onderverdeling en controle moet zijn terwijl het jezelf geen tijd en geld kost. Dus hoe zie je het voor je? Iemand anders moet het maar gaan regelen? Dat is hoe het nu ook werkt. De wet geeft mogelijkheid. Strengere wetgeving? Hoe denk je dat gedaan te krijgen? Meer handhaving? Wie gaat dat regelen en betalen?

Je voorstel klinkt logisch vanuit de gedachte dat alleen personen die met de data te maken hebben die data zouden moeten hebben zolang het nodig is. Vooral bij gegevens die iets over personen zegt. Daar is al wetgeving voor: de avg

Klopt. Dataminimalisatie is een logisch gevolg van de AVG. De wegt schrijft echter niet voor hoe je dat moet doen. Ik doe een voorstel tot verbetering.

Een nadeel is dat minimalisatie niet gelijk staat aan versimpelen. Het is makkelijk stellen dat er bijvoorbeeld meer onderverdeling en controle moet zijn terwijl het jezelf geen tijd en geld kost.

Waar zeg ik dat het mij geen tijd of geld mag kosten? Iedere vorm van beveiliging kost tijd en geld op korte termijn. De aaname achter iedere vorm van beveiliging is dat je die kosten op lange termijn terugverdient.

Dus hoe zie je het voor je? Iemand anders moet het maar gaan regelen? Dat is hoe het nu ook werkt. De wet geeft mogelijkheid. Strengere wetgeving? Hoe denk je dat gedaan te krijgen? Meer handhaving? Wie gaat dat regelen en betalen?

Eerlijk gezegd snap ik de helft van je vragen niet goed, maar ik zal toch proberen te antwoorden.
Momenteel is het praktisch gezien zo dat winkeliers moeten bijhouden wie hun klanten zijn. Dat is onder andere nodig om te zorgen dat het pakketje bezorgd kan worden, voor retouren en garantie en om te zorgen dat er geen alcohol wordt verkocht aan minderjarigen. Die wetten zijn er met goede doelen maar staan mijn model in weg. Die wetten moeten zo worden aangepast dat mijn voorstel mogelijk wordt zonder met de oorspronkelijke doelen te conflicten. Welke aanpassingen er precies nodig zijn weet ik ook niet, dat zal moeten worden onderzocht, net als bij iedere aanpassing van de wet.

Omdat er verregaande samenwerking nodig is tussen bezorgers (of dat nu gaat om post, paketten of pizza's), winkels en klant zal daar inderdaad een coordinerende organisatie voor moeten worden opgericht. Of dat door de staat moet worden gedaan of door de markt is niet zo belangrijk voor mijn idee.

Mijn stelling is dat het te makkelijk is om alleen te noemen wat er nodig zou zijn of een wens hoe dat vorm heeft. Wat je noemt is namelijk niet nieuw.

Wat stats van de dump, na uitfilteren ongeldige emails:

• 2.065 lijkt op SHA-512 maar niets gekraakt
• 4.741 lijkt op MD-5 maar niets gekraakt
• 1.631 phpass
• 358.989 bcrypt
• rest: via aanmelding social media accounts, dus geen wachtwoordhashes gestolen

De hashes die op rauwe SHA-512 en MD5 lijken, zijn waarschijnlijk iets anders aangezien we er tot op heden 0 van gekraakt hebben. Dat is nogal onwaarschijnlijk voor snelle hashes als SHA-512 en MD5. Onze gok: er zit een salt bij die niet in dump staat of op onbekende wijze uit de andere data gehaald wordt.

phpass is salted en heeft iteraties. Bevestigd kraakbaar, niet heel snel, niet heel traag.

bcrypt is prima manier van wachtwoordhashing. De gebruikte zogenaamde workfactors van Foodora zijn 10 (17k) en 11 (341k). Tien is prima. Elf nog beter. Bcrypts met deze workfactors (= 2^10 en 2^11 iteraties, dus 11 twee keer zo traag als 10) zijn relatief moeilijk te kraken. Wij hebben daar echter wel wat mooie apparatuur voor, op basis van FPGA's

Hoe is het mogelijk dat een bedrijf dat is opgericht in 2014 gebruik heeft gemaakt van MD5, terwijl al in 2004 bekend was dat deze encryptie niet meer veilig is. En misschien zelfs nog wel eerder. Hier zouden ze de verantwoordelijken van mij best voor mogen vervolgen. Dit is gewoon onkunde/laksheid en dient bestraft te worden.

Oof, dat is wel een probleem. Ik vraag mij af wie er nu verantwoordelijk kan worden gehouden voor dit datalek? Ik neem aan dat het bedrijf 'opgeheven' is bij de KvK.

In ieder geval hadden de gegevens vernietigd moeten zijn...

Het bedrijf Foodoora bestaat nog steeds he. Dat het in Nederland niet meer actief is, betekend niet dat het helemaal niet meer bestaat. Volgens mij is het alleen nog actief in Scandinavie op het moment.

Overigens hadden ze natuurlijk wel de informatie van 'Nederlandse klanten' kunnen verwijderen. Maar wat maakt iemand een Nederlandse klant? Iemand die alleen in Nederland bij het bedrijf heeft besteld, of als je bijvoorbeeld op vakantie in Zweden (als Nederlander) eten laat bezorgen in je hotel? Ben je dan ook een 'Nederlandse klant'? Zelf heb ik Foodoora alleen gebruikt toen ik voor het werk in Scandinavie was een paar jaar terug...dus weet niet of ik dan gezien zou worden als een NL klant. Het enige wat 'Nederlands' aan mij was was het mobiele nummer en misschien mijn naam.

[Reactie gewijzigd door TheVMaster op 16 juni 2020 10:16]

Er staat dat de SQL databases verdeeld waren per land. Dus ze hadden de Nederlandse database kunnen verwijderen...

Er staat dat de SQL databases verdeeld waren per land. Dus ze hadden de Nederlandse database kunnen verwijderen...

Bijzonder dat ze dit niet gedaan hebben. Wat wilden ze met de data gaan doen? Doorverkopen, evt. gebruiken voor een comeback?

Een bedrijf heeft in mijn ogen hier gewoon onnodig risico's gelopen die helemaal niet nodig waren. Ik vind dat ze dit wel heel erg kwalijk genomen mag worden en anders met een heel goed argument moeten komen waarom ze het bewaard hebben.

Dat hadden ze dan inderdaad wel kunnen doen! :-)

Hadden ze kunnen doen, maar zou de fiscus wellicht niet zo blij mee zijn.

De fiscus is niet geïnteresseerd in de bestelgeschiedenis van klanten, noch in hun adressen. Dus die informatie had gewist kunnen worden.

Ik vind dit bijzonder slordig en ik mag hopen dat ze hangen met een dikke boete. En nee, ik heb er nooit iets besteld.

Wel in facturen. Laat dat nou de bestelgeschiedenis en klantinformatie zijn. Daarnaast zijn de accounts gewoon nog actief naar ik begrijp. Het enige dat slordig zou kunnen zijn, is het niet offline archiveren ipv in de systemen laten hangen.

[Reactie gewijzigd door TWeaKLeGeND op 16 juni 2020 11:12]

Precies, en vaak worden facturen on the fly gegenereerd met gegevens uit deze databases. Dus database verwijderen betekent dan soms dat je facturen ook niet meer werken omdat die gevoedt worden uit die database. Je kunt wel overal PDFjes van gaan opslaan maar vaak is het genereren wanneer het nodig is een stuk goedkoper qua opslag.

Je zou denken dat Nederlandse klanten zijn klanten met een locatie in Nederland.

Als ik naar Duitsland op vakantie ga en daar eten bestel met aflever adres iets in Duitsland, ben ik dan Nederlandse klant of Duitse klant? Foodora ziet die klanten niet als Nederlands of Duits, maar als klanten. Klanten die toevallig op dat moment niet in de buurt van een Foodora zitten, maar nog steeds potentiële klanten. Als ik wat bestel bij Amazon.com, .co.uk of .de dan gooien ze me toch ook niet direct uit de database omdat ik niet in de VS, UK of Duitsland woon. Of toen Amazon.nl actief werd, zou ik het heel slecht hebben gevonden als ik uit de db was gegooid onder de aanname dat ik nu altijd via .nl zou bestellen...

Amazon is week een slecht voorbeeld, het account wordt gedeeld over de diverse portals (nl de uk) maar bij de eerste keer moet je je wel “aanmelden” en wordt je automatisch weer bij allemaal nieuwsbrieven en andere spam van Amazon ingeschreven...

In dit geval van foodora hadden ze gewoon de database offline moeten halen, gevalletje van vergeten Nederlands systeem dat nog aan internet hangt? Of is gewoon hun hele klantenbestand gejat (de omschrijving van lokale databases/per land doet vermoeden het eerste).

Er zijn 727.000 accounts gestolen, waarvan 50.000 Nederlanders, dat is dus niet puur een Nederlandse database. Dat lijkt de database te zijn van het hele concern, welke nog actief is.

Ah overheen gelezen!

Een Nederlandse klant is een klant die bestelling deed via de Nederlandse afdeling. Een Nederlander in Scandinavië is een Scandinavische klant in dit geval.

Vakanties, werken in het buitenland, stages. Genoeg mogelijkheden om tijdelijk in een ander land te zijn toch?

Dus Nederlanders die (wel eens?) bij een Nederlandse vestiging hebben besteld? Is wat mij betreft te kort door de bocht. Wat als ik nu ook wel eens in Nederland had besteld, maar ook in Scandinavie (want daar kom ik voor m'n werk). Hadden ze mijn account dan maar moeten verwijderen?

Je snapt hopelijk wel wat ik bedoel, het is niet zo simpel om 'zomaar' klantgegevens te verwijderen puur omdat een bedrijf zijn operatie in Nederland stopt.

Vaak moet je jezelf opnieuw registreren in een ander land, dit ben ik zelf in ieder geval vaak tegen gekomen bij bedrijven als Thuisbezorgd (Lieferando in Duitsland, Takeaway in België). Hierdoor staat misschien alles in één database maar worden er andere front-ends aangeboden per land en kun je jouw account niet gebruiken in een ander land.

Je kan ook te ver gaan. Laat een ander lekker in zijn waarde. Hij geeft gewoon een normaal antwoord.

Als ze hun Duitse vestiging hadden gebruikt om in Nederland te opereren (dus geen dochter-BV) hadden ze volgens mij die gegevens minstens 7 jaar moeten bewaren van de belastingdienst, zodat die desnoods een audit kan doen en belasting kan naheffen.

In de database zaten ook wachtwoorden met de zwakke MD5-hash

MD5 in 2015 kan echt niet maar het klinkt enigsinds als een artifact uit het verleden, nog steeds slecht maar goed. Het kan zijn dat men de update van die accounts nooit heeft uitgevoert als het enkelen zijn met een oude 'last login'. Als iemand niet inlogt valt er weinig te updaten naar nieuwe methoden.

Sinds 1996 wordt er al gezegd gebruik het niet maar gebruik SHA-1. Sinds 2006 is SHA-1 al niet meer aangeraden voor secure hashing, maar moet je SHA-2 gebruiken. In 2015 MD5 gebruiken is niet alleen foei, maar zou gewoon strafrechtelijk vervolgd moeten worden.

Waarom wordt een bedrijf dat zijn activiteiten stopt in Nederland niet verplicht Om alle data van zijn Nederlandse gebruikers te vernietigen?

Tja...en als ik als Nederlandse klant ook wel eens bij een buitenlandse vestiging eten bestel? Dat maakt het natuurlijk wel ingewikkeld.

Je moet het niet moeilijker maken dan het is.

Gewoon de klantgegevens die in de database staan droppen waarvan de registratie met een Nederlands IP adres heeft plaats gevonden OF voor de eerste keer op een Nederlands adres heeft besteld.

Mochten er buitenlandse accounts verwijderd zijn, kunnen ze altijd nog een nieuwe account maken en/of zijn het maar enkelen die weer uit de backups terug kunnen worden gezet.

Dan ben je nog klant van dat bedrijf.
Wanneer een bedrijf de activiteiten staakt wat is dan onder de huidige AVG de grondslag om deze gegevens te blijven bewaren?

Waarom wordt een bedrijf dat zijn activiteiten stopt in Nederland niet verplicht Om alle data van zijn Nederlandse gebruikers te vernietigen?

Geld.

Omdat die data veel geld waard is. Als bedrijven er mee stoppen, zeker als ze failliet gaan dan wordt alles van waarde er uit getrokken. De nieuwe eigenaar van de data schuift alle verantwoordelijkheid af op het failliete bedrijf, dat maar beter toestemming had moeten vragen of voor betere beveilging moeten zorgen.

Omdat veel internetbedrijfjes geen andere bezittingen hebben dan de laptop van de baas en de data van de klanten wordt er al snel naar die data gekeken als er schulden moeten worden terugbetaald. Ik kan me voorstellen dat er een groep is (investeerders en schuldeidsers enzo) die het prima vinden dat er nog een manier is om waarde uit een falliet bedrijf te halen, ook al gaat dat ten kosten van de voormalige klanten.

Verplicht door wie? Is daar regelgeving voor om een bedrijf dat op te leggen?

Ja, de AVG. Volgens mij mag data niet langer bewaard worden dan nodig.

Omdat de toko die denkt boven alle wetten te staan (en ook daadwerkelijk veel macht heeft) daar niet blij mee zou zijn. Ik bedoel die blauwe enveloppen toko ja.

kreeg via haveibeenpowned een waarschuwings mailtje. Erg balen, combi email+echte naam +adres ben ik niet blij mee dat het op staat ligt. Maar ja, iets wat ik nog kan doen????

Verhuizen, naamsverandering en ander e-mailadres nemen
Anders dan nagaan of het wachtwoord wat je hier hebt gebruikt of je dat op andere plekken hebt gebruikt en dat overal naar iets nieuws wijzigen. Verder kan je weinig doen.
Wat zou je willen doen dan?

Een rechtzaak starten tegen foodora zou een optie kunnen zijn. Maar er zal niet veel te halen zijn vooral omdat je geen directe schade zal kunnen aanwijzen (vermoedelijk).

Als eigen accountbeheer goed op orde is - is het probleem te overzien, toch.
Voorbeeld: Ik zit ook het bestand van de Jehova getuigen. Zo af en toe bellen ze aan, prima. Ik luister en wenst hen succes in het zoeken naar de waarheid.

Oef, ben ik even blij dat ik na één keer bestellen mijn account had verwijderd.

Ik werd ooit klant omdat ik een kortingscode van Foodora kreeg. Maar bij de tweede keer zonder kortingscode moest je voor bezorgen minimaal €25 aan eten bestellen ongeacht welk restaurant
Daarom zag ik geen reden om langer klant te blijven.

Zoveelste voorbeeld waar ik niet van sta te kijken. Het grootste probleem bij een datalek is het wachtwoord die ze kunnen achterhalen om vervolgens te proberen bij andere accounts. Hiermee zouden ze bij belangrijkere gegevens kunnen of je ID overnemen. Als je een wachtwoord moet invoeren zorg dan altijd dat je een random wachtwoord aanmaakt uniek voor elk account.