Carpetright waarschuwt dat gehashte wachtwoorden mogelijk zijn gestolen

Carpetright waarschuwt klanten voor een potentieel datalek. Het bedrijf heeft te maken gehad met een incident, waarbij mogelijk gehashte wachtwoorden zijn gestolen. De vloerenverkoper heeft alle wachtwoorden uit voorzorg gereset.

Verschillende tweakers hebben bericht gekregen van Carpetright. Het bedrijf ontdekte op 19 februari een datalek. Carpetright vertelt niet wat de aard van het datalek is. "Onze analyse bevestigt dat gehashte versies van gebruikerswachtwoorden ook deel uitmaakten van het datalek", schrijft Carpetright. "Je ontvangt deze e-mail omdat de gehashte versie van het wachtwoord dat je op ons systeem hebt aangemaakt was opgenomen in het lek."

Het bedrijf zegt in een reactie aan Tweakers dat het niet zeker is of de gegevens daadwerkelijk zijn gestolen. "We hebben securitybedrijf NFIR ingeschakeld voor forensisch onderzoek. Die kijken in de logs of de gegevens echt zijn gedownload." Een woordvoerder van Carpetright zegt dat het bedrijf uit voorzorg heeft gehandeld en klanten daarom heeft geïnformeerd.

Carpetright zegt op 19 februari te hebben ontdekt dat de back-end van de website was geïnfecteerd met malware. Welke malware dat is, is niet bekend. Carpetright zegt dat het in ieder geval niet om ransomware gaat. Bij de inbraak zijn mogelijk namen, adressen, telefoonnummers en e-mailadressen van klanten buitgemaakt. Daarnaast kan het zijn dat de inbrekers toegang hadden tot wachtwoorden; die waren volgens Carpetright in dezelfde database opgeslagen. De wachtwoorden waren met SHA-256 gehasht en bevatten een salt, aldus Carpetright. Betaalgegevens stonden in ieder geval niet in de database.

Bij de inbraak waren mogelijk de gegevens van alle 30.000 Carpetright-accounthouders inzichtelijk. Daar zaten ook Belgische gebruikers bij. Het bedrijf heeft daarom niet alleen melding gemaakt van een datalek bij de Nederlandse Autoriteit Persoonsgegevens, maar ook bij de Belgische Gegevensbeschermingsautoriteit.

Reacties (24)

[ultimasnake]

Jammer dat ze geen melding maken over de type encryptie, als het MD5 is (zoals de AI tool eerder vandaag) dan is het toch echt wel een potentieel probleem gezien het gros. van de mensen nog steeds hetzelfde wachtwoord overal herkauwen...

[mrwiggs]

Hashing is geen vorm van encryptie. MD5 is een hashingalgoritme.

[graceful]

De wachtwoorden waren met SHA-256 gehasht en bevatten een salt, aldus Carpetright. Betaalgegevens stonden in ieder geval niet in de database.

Zoals hier bedoel je?

[The Third Man]

Ik hoop alleen niet dat de salt te vinden is door het voorbeeldje met Tapijt123!

[fvbommel]

Salt is als het goed is uniek per account, dus wordt het gebruikelijk in dezelfde database opgeslagen als de hash zelf (vaak zelfs in het zelfde database-veldje). Als ze de hashes hebben hebben ze dus naar alle waarschijnlijkheid ook de bijbehorende salts.

Salt is niet zozeer bedoeld om geheim te blijven als de database gelekt wordt, maar meer om te voorkomen dat verschillende accounts met hetzelfde wachtwoord ook dezelfde hash hebben. Zo voorkom je dat aanvallers alle wachtwoorden tegelijk kunnen raden door een hoop wachtwoord-achtige strings door een hash functie te halen en dan te kijken welke account(s) matchen. Door het salt moet dus je bij nul beginnen met het kraken van iedere individuele account.

Als je voor iedere account dezelfde (hopelijk moeilijk te achterhalen) data toevoegt aan wachtwoorden voordat ze gehasht woorden, heet dat pepper of simpelweg een geheime sleutel (secret key). Die hoeft dan natuurlijk niet in de database opgenomen te worden, en is dus mogelijk beter te verbergen voor aanvallers. Dit is typisch niet bedoeld als vervanging voor een salt, maar als extra toevoeging erbovenop.

[graceful]

Moet wel zeggen dat het eerst is dat ik een e-mail zie die een poging doet om mensen echt uit te leggen wat een hashed wachtwoord is.

Bij de inbraak zijn mogelijk namen, adressen, telefoonnummers en e-mailadressen van klanten buitgemaakt.

Alsnog ben ik enorm voorstander van hele andere aanpak m.b.t. data bewaren. Er zullen enkel meer en meer databases gehackt/gekraakt/verloren/ingebroken worden. Er is geen reden om klanten data voor jaren te bewaren, als je enkel voor je (imho archieved) accounting nog klant informatie nodig hebt.

Kans groot, kleine aanname, dat hier weer allemaal inactieve gegevens bij zaten. Mensen die dat account al jaren niet gebruiken.

[mauritsdej]

Ik heb het idee dat ze enige inspiratie hebben opgedaan bij EasyPark...
https://media.licdn.com/d...yqhO7_Xpk6a3SYzkJacg76ziQ

[locke960]

Of ze hebben hetzelfde bedrijf in de hand genomen, met communicatie templates als onderdeel van de dienstverlening.

[d22wth]

Dat is niet heel erg, toch? Als het voor de meeste digibeten te begrijpen is?

[Hagdos]

Beter goed gejat dan slecht verzonnen.

[Quintiemero]

Eens, helaas blijft het vaak bij een beleid. Maar daadwerkelijke implementatie van actieve verwijdering is vaak ver te zoeken.

[Frame164]

Ik ben het helemaal met je eens dat dit soort informatie na een tijdje gewoon weggegooid kan worden. Maar onderschat de klaagkracht van consumenten niet. Stel iemand heeft ooit een account aangemaakt en wil na een tijdje nog een keer wat bestellen. Normale mensen nemen contact op met een bedrijf als iets niet lukt, maar steeds meer mensen gaan eerst online klagen en een bedrijf voor van alles en nog wat uitmaken. Vervolgens gaan anderen even googles op een bedrijfsnaam en zien ze de klachten. Dat heeft gewoon impact op een bedrijf.

[Reactie gewijzigd door Frame164 op 22 juli 2024 13:56]

[tvtech]

inderdaad een erg duidelijke mail met de aanbeveling om, als je dit wachtwoord op meer plekken gebruikt, het daar ook moet wijzigen. Easypark heb ik juist een slechte mail van ontvangen destijd, eigenlijk net zo slecht als dat de app is.

Ik had gelukkig een uniek wachtwoord en ik ben het met je eens dat er veel accounts bij zullen zitten die 1 keer gebruikt zijn. Want je huis richt je niet wekelijks of maandelijks in.

[Tintel]

allemaal inactieve gegevens bij zaten

tja, de ellende is: een e-mail adres is vaak niet heel 'vluchtig' en rekeningnummers ook niet. Dus ook al is het account al jaren niet meer gebruikt - de data is misschien nog wel juist.

[watercoolertje]

Lekker dan, hebben ze mijn wachtwoord als voorbeeld gebruikt in die email...

De wachtwoorden waren met SHA-256 gehasht en bevatten een salt, aldus Carpetright. Betaalgegevens stonden in ieder geval niet in de database.

Vind dit best netjes als je het naast het eerdere datalek van vandaag houdt waar wachtwoorden nog dmv MD5 gehasht waren!

[laurxp]

Tsja. SHA-256 met salt is al een flink aantal jaren het minimum dat je verwacht van een niet compleet incompetente partij: MD5 is al sinds 1996 met pensioen, en SHA-1 sinds 2010. Anno 2024 verwacht je eerder iets als scrypt of bcrypt bij partijen die beveiliging serieus nemen.

[MacGyverNL]

Correctie: PBKDF2 met salt is al een flink aantal jaren het minimum dat je verwacht, en het boeit niet eens zoveel of dat dan intern MD5 of SHA1 of SHA-256 gebruikt.

Ik stoor me dan ook aan dat niet duidelijk uit dit bericht blijkt of het single-pass SHA-256 of een multi-round KDF zoals PBKDF2 is. Want als het single-pass SHA-256 is, ga er dan maar van uit dat alle zwakke wachtwoorden en alle "sterke" wachtwoorden korter dan 12 tekens gewoon gecompromitteerd zijn.

[Mandrake466]

Tapijt123! is een veel voorkomend wachtwoord dus je bent niet de enige.

[Johnvh]

Goed dat ze het niet onder het tapijt schuiven...

[Bas_f]

Zeker. Wel fijn dat ik daar niet over de vloer kwam.

[paulwump]

Misschien kan je de gehashte wachtwoorden binnenkort wel in een koffieshop kopen...

Cash voor gehasht... wilt U hem los of voorgedraaid..

[watercoolertje]

Jij hebt je wachtwoord zeker al opgerookt voordat ie uitgelekt kon worden?

[droofx]

Carpetright is geen vloerenverkoper maar een vloerbedekkingverkoper

[aukeb]

Dat is niet zo gek want als je bij Carpetright iets gaat bestellen dan komt er een blauw scherm met witte vakjes te voorschijn waar ze nog met tab toets doorheen moeten omdat de muis niet werkt. Systeem is nog uit jaar nul.