Batterijenhuis.nl waarschuwt klanten voor een datalek

De accu- en batterijenwebwinkel Batterijenhuis.nl heeft een deel van zijn klanten ingelicht over een datalek. Criminelen wisten persoonsgegevens van klanten weg te sluizen. Het lek treft ongeveer vijftien procent van de klanten.

De gegevens die de criminelen in handen kregen, betreffen onder andere naam, adres, woonplaats, e-maildres en wachtwoord. Volgens de webwinkel zijn wachtwoorden gehasht. "De kans dat er iets met deze lijst wordt gedaan, achten wij klein, omdat het bijzonder lastig is deze lijst te ontsleutelen", meldt het bedrijf aan de getroffen klanten in een dinsdag verzonden e-mail. Details over de gebruikte hashmethode geeft Batterijenhuis.nl niet. De winkel adviseert klanten uit voorzorg hun wachtwoord te wijzigen.

De winkel benadrukt dat bankrekening- of creditcardgegevens niet zijn gestolen. Deze werden niet door Batterijenhuis.nl opgeslagen. In een reactie aan Tweakers laat de shop weten geen uitspraken over precieze aantallen te doen, maar dat het om vijftien procent van de klanten met een account gaat. "Tot 3,5 jaar geleden werkten we met osCommerce, sindsdien zijn we overgestapt naar OpenCart. Het gaat om de klanten die in osCommerce een account hadden aangemaakt en in de tussentijd niet hun wachtwoord hebben aangepast."

De criminelen kwamen binnen via een op maat gemaakte module voor de site. "Die module werd door verschillende updates niet meer goed gemonitord", aldus de accuwinkel. Op de dag na ontdekking is het lek gedicht, maar niet bekend is hoe lang dit aanwezig was. Batterijenhuis.nl geeft aan de Autoriteit Persoonsgegevens nog niet te hebben ingelicht over het datalek. "We moesten eerst onze klanten informeren en daarna de verschillende instanties informeren. Dit wordt deze week nog gedaan."

Reacties (55)

[eborn]

Tja, ik beschouw naam, adresgegevens en e-mailadres eigenlijk al als publieke informatie, ook al staan je adresgegevens niet (meer) standaard online in een telefoongids. Inmiddels zijn er zoveel hacks geweest, dat die gegevens al lang in het criminele circuit bekend zijn. En wachtwoord hashes zijn vervelend, maar mits goed gehashed weinig bruikbaar.

Niet dat ik dit soort hacks wil goedpraten, maar zolang het geen gegevens zijn waardoor er identiteitsfraude kan plaatsvinden, maak ik me weinig zorgen. Ik kan me voorstellen dat het voor mensen die, om veiligheidsredenen, niet publiek vermeld willen worden wel vervelend is.

[Baris]

Niet dat ik dit soort hacks wil goedpraten, maar zolang het geen gegevens zijn waardoor er identiteitsfraude kan plaatsvinden, maak ik me weinig zorgen.

De gelekte gegevens plus een combinatie van andere gegevens kunnen het begin zijn van identiteitsfraude.

Elke vorm van een lek is 1 te veel. Dus ja, als ik was getroffen zou ik mij wel zorgen maken

[eborn]

In de meeste gevallen zal bij het uitlekken van bijzondere persoonsgegevens (BSN) toch al meer informatie uitlekken. En als dat niet het geval is, dan is er weer geen mogelijkheid om de informatie aan deze informatie te koppelen.

Op het moment dat een naam en adres voldoende is om identiteitsfraude te plegen, kunnen we beter stoppen met identificatie in het algemeen. Eigenlijk is het al absurd dat het soms met naam, adres en IBAN nummer lukt om incasso's te laten uitvoeren.

[fastedje]

Er was een aantal jaren geleden een voorbeeld bij Zembla of Brandpunt over een zakenman die met grote regelmaat op schiphol werd aangehouden. Bleek dat een crimineel bij een aanhouding zijn naam had genoemd en deze kwam om databases van diverse overheidsdiensten terrecht. Na regelmatig opnieuw een verzoek tot verwijdering uit de database bij de politie te doen kwam zijn naam naar een tijd weer terug in het systeem door diverse datasyncs tussen de databases. Zijn zakenrelaties vertrouwde de beste man niet meer en zijn reputatie was weg.
Moraal van het verhaal: als je echt pech hebt dan is alleen een naam al voldoende om je leven te ruïneren.

[Bensimpel]

Nouja als ik je emailadres weet, plus je fysieke adres kan ik zo je achternaam gebruiken voor een fysieke nep brief.

Brief van de gemeente ofzo, waarbij je in een vreemde site moet inloggen, tweakers zullen daar niet zo snel intrappen maar de gewone man?

Offline phising, dus dat is wel gevaarlijk.

[Verwijderd]

Maar voor een combinatie naam en fysiek adres heb je geen datalek nodig. Huur een aantal scholieren in die naambordjes van woningen overschrijven met het adres en je bouwt zo een volledig legale database op. Het kost wat meer, maar principieel is het hetzelfde.

PS: die nepbrief moet je nog altijd ondertekenen als het echt belangrijk is.

[hellum]

Dat ondertekenen lijkt me nou niet echt een groot probleem, ik weet eerlijk gezegd niet eens wie de huidige burgemeester (of wie ook maar moet tekenen) is, laat staan dat ik zijn/haar handtekening herken.

[Zebby]

Je wilt hoe dan ook niet dat enige informatie van jou gelinked op het internet komt. Ieder lek leidt tot een immer groeiende database waarbij er gekoppeld kan worden op meer en meer data om een zo consistent mogelijk profiel te kunnen vormen. Volgens de GDPR valt dat allemaal netjes onder persoonlijke informatie en daarmee is het een datalek.

Feit dat ze niet willen aangeven welke hashing methode is toegepast geeft ook niet veel vertrouwen. Het is wel beter dan plaintext of encrypte wachtwoorden.

[himlims_]

De kans dat er iets met deze lijst wordt gedaan, achten wij klein, omdat het bijzonder lastig is deze lijst te ontsleutelen
> dan huur je toch "even" dit wat extra rekenkracht bij eoa cloud dienst - of laat je botnetje het uitzoeken.

[RGAT]

Als dat een degelijke hash functie is zal dat een duur geintje worden voor zelfs maar 1 wachtwoord, laat staan een lijst van honderden? of duizenden?
Wel wordt er hier boven gespeculeerd dat er misschien nog MD5 gebruikt werd, in dat geval kan het vanaf de laptop thuis nog zelfs...

Ik heb even kort rond gekeken in de source en kom deze comment tegen:

# We're kind of forced to use MD5 here since it's the only
# cryptographic primitive available in all versions of PHP
# currently in use. To implement our own low-level crypto
# in PHP would result in much worse performance and
# consequently in lower iteration counts and hashes that are
# quicker to crack (by non-PHP code).

Gevolgd door de functie:

if (PHP_VERSION >= '5') {
$hash = md5($salt . $password, TRUE);
do {
$hash = md5($hash . $password, TRUE);
} while (--$count);
} else {
$hash = pack('H*', md5($salt . $password));
do {
$hash = pack('H*', md5($hash . $password));
} while (--$count);
}

Om de een of andere reden controleren ze wel of er een nieuwere PHP versie gebruikt wordt, maar plaatsen ze daar dan niet een passende hash functie maar ook gewoon MD5, welliswaar met wat loopjes erin maar echt veel beter is het niet...
Wat weinig vertrouwen schept... Oftewel sowieso direct alle diensten etc. waar je hetzelfde wachtwoord gebruikt maar vernieuwen

Edit: PHP tags blijven lastig op Tweakers
Dan maar in een quote... Als iemand mij kan leren normale PHP tags te gebruiken...

[Reactie gewijzigd door RGAT op 22 juli 2024 20:47]

[Stoelpoot]

> Oftewel sowieso direct alle diensten etc. waar je hetzelfde wachtwoord gebruikt maar vernieuwen

Beter nog, direct een wachtwoordmanager instellen zodat je de volgende keer het wachtwoord niet voor andere diensten meer gebruikt

[Dreamvoid]

Totdat je wachtwoordmanager wordt gekraakt.

[indigo79]

Er zijn ook offline wachtwoordmanagers. Het is niet helemaal onmogelijk dat er iemand dan nog met je wachtwoorden aan de haal gaat, maar de kans is toch een stuk kleiner dan online. Ik heb in mijn wachtwoordmanager intussen ruim meer dan 100 entries staan, geen schijn van kans dat ik daar unieke wachtwoorden voor kan onthouden.

Maar met alle gedoe is het papiertje in de lade van je bureau misschien nog de veiligste optie. :-)

[mcDavid]

Wat weinig vertrouwen schept... Oftewel sowieso direct alle diensten etc. waar je hetzelfde wachtwoord gebruikt maar vernieuwen

Dat is sowieso belangrijk als een dergelijke database uitgelekt is. Dat de passwords gehashed zijn zorgt dat je voldoende tijd hebt om dat te doen, maar je kunt er niet meer vanuit gaan dat een password waarvan de hash gelekt is, voor altijd privé zal blijven. Hoe sterk die hash ook is.

Als het inderdaad MD5 geweest is, is die tijd idd een kwestie van minuten.

[himlims_]

[code][code=php][/code][/code] schijnbaar alleen op got

[Reactie gewijzigd door himlims_ op 22 juli 2024 20:47]

[michaelboon82]

Dom van ze want PHP heeft sinds versie 5.5 het degelijke password_hash() en password_verify(). Zelfs als ze sinds PHP4 de MD5-based crypt() functie gebruikt zouden hebben zouden ze nu makkelijk over kunnen stappen naar password_verify() omdat die de door crypt() gegenereerde wachtwoorden kan verwerken.

[donaldk]

Daarom maak ik in principe nooit een account aan. Ook niet die ene keer dat ik bij batterijenhuis en een concurrent knoopcellen en andere wat apartere batterijtjes moest bestellen. Helaas biedt niet elke online winkel de 'doorgaan als gast' of andere loginloze bestelmogelijkheid.

[blissard]

Triest dat het gebeurt, maar goed om te zien dat de reacties van bedrijven hierin wel professioneler wordt.

[Tozz]

Het is vrij treurig dat het osCommerce pakket dat ze bljikbaar al 3,5 jaar niet meer gebruiken nog steeds online stond.

[Whatts]

Ik heb ooit eens voor een (intern) systeem voor mijn werk iets gelijkaardig moeten doen, voor het overschakelen van een oud login-systeem naar een nieuw. Al wie vanaf een bepaald moment inlogde, werd automatisch naar het nieuwe systeem omgezet (watchwoorden waren in het oude systeem ook al hashed, dus enkel op het moment van inloggen beschik je over het "plain text" wachtwoord). Daardoor kan je (zonder dat de user het merkt of een wachtwoord (terug) moet instellen) op dat moment een user verhuizen van het oude naar het nieuwe systeem (en dan automatisch uit het oude systeem deleten). Het gevolg is wel dat je een tijd lang parallel 2 systemen naast elkaar draait, dus op een gegeven moment moet je wel de beslissing nemen om het oude systeem er uit te halen (en users die al die tijd nog niet ingelogd hadden dan toch verplichten een nieuw wachtwoord in te stellen).

[Tozz]

Mooi, maar:

- Die migratie hoeft geen 3,5 jaar te duren.
- Je kunt ook iedereen een password reset geven (waarschijnlijk ook veiliger)
- Je kunt meestal ook wel de hashed wachtwoorden meenemen naar het nieuwe systeem, al dan niet met een kleine code aanpassing.
- Als je toch voor deze optie gaat die jij beschrijft, zorg dan dat je ook het oude systeem blijft onderhouden

Dit is gewoon vrij dom. Het lijkt er meer op dat ze de oude code gewoon hebben laten staan en nooit meer naar omgekeken hebben.

[Morress]

Bewaarplicht miss? Geen idee. Maar dat zou ook offline kunnen

[Tozz]

Dat je de data niet weggooit prima, maar inderdaad, zet het dan offline ergens neer. Als de site is gehacked via een module in OsCommerce dan stond die webshop blijkbaar nog ergens publiek bereikbaar.

[Mathi159]

Zal wel moeten, is tegenwoordig verplicht

[laptopleon]

En iedereen houdt zich aan de wet natuurlijk.

[WouterL]

Ze zullen eigenlijk ook wel moeten.

[tweaker2010]

"De kans dat er iets met deze lijst wordt gedaan, achten wij klein, omdat het bijzonder lastig is deze lijst te ontsleutelen". De lek an sich is misschien niet te voorkomen, maar dit zinnetje geeft mij geen vertrouwen.

[dinoballz]

Even snel Googlen lijkt te tonen dat OsCommerce, een shopping cart systeem waarin iedereen makkelijk een webshop kan aanmaken, MD5 gebruikt voor pw hashing.

Echter zijn de gevonden artikelen wel al 9-12 jaar oud, het kan dus zijn dat daar nog verbeteringen in zijn doorgevoerd. Ook al was MD5 in 2004 al gekraakt.

[i2Paq]

Ligt ook aan welke versie van osC er gebruikt wordt en dit geldt natuurlijk ook voor OpenCart.

[Verwijderd]

Op Github https://github.com/osCommerce/oscommerce kun je in ieders geval zien dat osCommerce al 7 jaar niet meer geupdate is, en dat ze dus ook nog altijd md5 gebruiken https://github.com/osComm...arch?q=md5&unscoped_q=md5

[Aaargh!]

Een blik op de source code laat zien dat er iig in versie 3.x uit 2011 nog gebruik gemaakt werd van MD5.

[Reactie gewijzigd door Aaargh! op 22 juli 2024 20:47]

[cappie]

https://github.com/haraldpdl

Die Harald is de boosdoener?

[HyperioN]

"De kans dat er iets met deze lijst wordt gedaan, achten wij klein, omdat het bijzonder lastig is deze lijst te ontsleutelen"

Nou, daar zou ik niet zo zeker van zijn.
OSCommerce gebruikt namelijk md5 om passwords te hashen, zie:
https://github.com/osComm...rce/OM/Core/Hash/Salt.php
en een uitleg van die code op:
http://ryanuber.com/09-24...rce-password-hashing.html

Ja, dit is code uit 2010/2011 maar zo te zien is dat sindsdien dus ook niet aangepakt! (Volgens mij wordt heel osCommerce niet echt meer doorontwikkeld).

Van md5 is bekend dat deze enorm gemakkelijk te decrypten is (https://en.wikipedia.org/...erview_of_security_issues)

Weliswaar voegen ze een random string toe, maar dat lijkt me ook wel overheen te komen.
Dus; mocht je klant zijn en daar een wachtwoord hebben gebruikt dat je ergens anders ook gebruikt: zeker je passwords aanpassen. (Dat moet je sowieso doen als je password ergens gelekt is; ook al is het geen md5).

Wel jammer dat deze partij weer zegt dat het "niet zoveel uitmaakt". Keer op keer blijkt dat bedrijven in de verdediging schieten als ze zoiets gebeurd. Kom op: wees gewoon eerlijk en transparant en zeg dat de wachtwoorden waarschijnlijk ontcijferd kunnen. Dan gaan Piet en Annie (die géén IT-kennis hebben) wellicht óók hun wachtwoorden op andere sites aanpassen; nu zullen ze dat waarschijnlijk gewoon laten zitten, en dat is wellicht nog schadelijker dan het lek in deze site zelf.

[Reactie gewijzigd door HyperioN op 22 juli 2024 20:47]

[CyberJack]

MD5 is niet te decrypten. MD5 is een hash methode en geen encryptie methode.
Er bestaand wel grote rainbow tables waarin een MD5 hash opgezocht kan worden.

Een ander probleem van MD5 is dat deze te kort is (128 bit) waardoor er meerdere stukken tekst zijn de zelfde hash opleveren. Een collision vulnerabilitiy dus. SHA1 (160 bit) heeft trouwens het zelfde probleem en is ook al tijden niet veilig genoeg meer.

Zelf toevoegen van vervuiling en het gebruiken van meerdere hash iteraties zal zeker helpen, maar doordat deze collision vulnerabilities bestaan zullen MD5 en SHA1 nooit meer echt veilig zijn.

[Reactie gewijzigd door CyberJack op 22 juli 2024 20:47]

[Verwijderd]

De ontwikkeling van OsCommerce ligt inderdaad al een aardige tijd stil. tegenwoordig maken veel webwinkels gebruik van een Fork zoals ZenCart.

[i2Paq]

Hmm, ik zie inderdaad dat osC nog steeds Hash MD5 gebruikt. Dat had ik niet verwacht.

Maar ja, het blijft gebaseerd op zeer oude code en wellicht is het lastig een db te updaten naar een nieuwe Hash als je migreert naar een nieuwe versie.

[theduke1989]

Ik vraag me af welke API ze voor Opencart gebruiken? want ik kan zelf niet echt vinden dat CC/ bankgegevens niet opgeslagen worden.

[Antrax]

Meestal via API's van Payment service providers wordt dat soort informatie teruggegeven en vaak slaan de payment modules in software als Opencart dit op in de database.

[theduke1989]

@Saven Ik gebruik Opencart al een tijdje nu. Maar bij mij wordt alles weergeven op de invoice pagina. CC en alles. Alleen ik als ADMIN heb rechten totdat gedeelde. Overige medewerkers niet.

Maar PayPal / Amazon Pay / iDEAL wordt gebruikt. Want met de iDEAL app maak ik alleen het actief.

[i2Paq]

Ik meen dat er geen CC gegevens on-versleuteld worden opgeslagen in de OpenCart database. Als dit wel gebeurd lijkt mij dat een issue van de Payment Module die gebruikt wordt.

Maar ik werk/bemoei me al een tijdje niet meer met OC dus helemaal zeker weet ik het niet, maar ik kan mij niet voorstellen dat 3.x dat standaard zou doen.

[eborn]

Het afhandelen van betaalgegevens, waaronder creditcard gegevens, vereist in de meeste gevallen dat je compliant bent met PCI-DSS. Het lijkt me sterk dat een systeem als OpenCart deze gegevens vervolgens klakkeloos in de database gooit, zelfs met encryptie. Je gebruikt juist een payment provider zodat je je met dit soort security zaken minder hoeft bezig te houden.

[Saven]

Gewoon via een payment provider, je hoeft zelf zulke data dan niet op te slaan.

[droner]

Alles wat je online doet en zeker alles wat je ooit invult in een formulier op welke website dan ook, komt hoogstwaarschijnlijk een keer op straat te liggen. Ik neem aan dat de meeste mensen dit inmiddels wel beseffen.

Het opslaan van persoonsinformatie mag m.i. dan ook nog wat verder teruggedrongen worden: ja, een winkel heeft je adresgegevens nodig voor een bestelling, maar zodra die ontvangen is zou standaard alles gedelete moeten worden. Kiezen mensen voor een account 'uit gemak' dan moeten ze zich realiseren dat ze, in ruil voor dat gemak, indirect praktisch gesproken alle betrokken info op straat gooien.

[Zenka]

De ondernemer mag de data niet verwijderen wanneer de aanschaf voltooit is. Facturen dienen 7 of zelfs 10 jaar bewaard blijven. Dit houd o.a. in welke partijen betrokken zijn, met hun naw gegeven.

Online shoppen zal altijd een financieel spoor achterlaten.

[Tjark]

Maar die hoeven niet online in het webshopsysteem zelf bewaard te worden voor zolang!

[RagingRaven]

Helaas gaat dat dan weer niet i.v.m. wetgeving:

https://www.belastingdien...maken/uw_facturen_bewaren

Facturen moeten in de vorm waarin ze verstuurd zijn, 7 jaar bewaard worden.
Normaal gesproken staat er op een factuur ook de adresinformatie.
Je zou wellicht deze gegevens offline kunnen opslaan of op een apart, niet met internet verbonden, machine, maar indien de factuur digitaal is verzonden, mag deze dus niet worden afgedrukt voor het bewaren (zie de opmerking in het gelinkte artikel).

Mijn inziens zijn adresgegevens dan ook totaal niet interessant (meer) voor identiteitsfraude, deze gegevens zijn overal en nergens terug te vinden. Ja idealiter zou je niets bekend willen hebben, maar we kunnen ook overdreven paranoide worden en het hele internet maar dichttimmeren.
Het is nu al een wirwar van banners, meldingen, opties en schermen voor dat je elke site mag bezoeken, laten we het internet a.u.b. ook een beetje werkbaar houden.

edit: Zoals Zenka's link nog eens aanvult, moeten NAW gegegevens dus zelfs verplicht bewaard blijven.

[Reactie gewijzigd door RagingRaven op 22 juli 2024 20:47]

[SinergyX]

[qouteDe kans dat er iets met deze lijst wordt gedaan, achten wij klein, omdat het bijzonder lastig is deze lijst te ontsleutelen[/]
Err..

naam, adres, woonplaats, e-maildres en wachtwoord

Een lijst wordt niet enkel gebruikt voor username/password, het wordt ook gebruikt voor identiteitsfraude, daar heb je toch een aardig leuk lijstje.

[Bensimpel]

Inderdaad, en ook zolang het niet duidelijk is welke versleutelen er gebruikt is zegt "lastig te ontsleutelen" niet erg veel.

Gewoon alle zelfde wachtwoorden uit voorzorg veranderen.

[Clemens123]

Alle zelfde wachtwoorden? Als dit het geval zou zijn, alle zelfde wachtwoorden die je hebt (niet enkel zelfde wachtwoord van deze site) veranderen in een uniek wachtwoord voor elke site.

[Bensimpel]

Ik bedoelde inderdaad indien je ww voor deze site gebruikt die op andere websites ook veranderen als je dus hetzelfde gebruikt.

Ik gebruik zelf een wachtwoord kluis (bit warden) voor iedere site maak ik een random wachtwoord aan en laat bitwarden inloggen voor me. Als 1 site lek is. Hoef ik maar 1x een ww te wijzigen.

[Antrax]

Batterijenhuis.nl geeft aan de Autoriteit Persoonsgegevens nog niet te hebben ingelicht over het datalek

Is het niet de bedoeling dat ze dat direct op diezelfde dag als de ontdekking moeten melden?

[JayOne]

Binnen drie dagen volgens de AVG-richtlijn:

"in de AVG bepaald dat de verwerkingsverantwoordelijke in geval
van een inbreuk verplicht is de inbreuk zonder onredelijke vertraging te melden en, indien mogelijk,
uiterlijk 72 uur nadat hij er kennis van heeft gekregen."

[wica]

Negatieve reclame is, ook reclame.
Ik kende ze niet.