Criminelen stelen wachtwoorden 157.000 klanten webwinkelketen Mapp

Webshop-uitbater Mapp heeft alle gebruikerswachtwoorden gereset nadat e-mailadressen en wachtwoorden van 157.000 klanten waren gestolen. Totdat gebruikers een nieuw wachtwoord instellen, zijn accounts bij webwinkels als InternGeheugen.com en MemoryMan.nl onbruikbaar.

Mapp raadt klanten aan om, als zij het wachtwoord dat ze gebruikten bij het account bij Mapp ook elders gebruikten, het wachtwoord ook daar te wijzigen. De gestolen wachtwoorden zijn weliswaar versleuteld, maar de kans bestaat dat de dieven ze kunnen ontsleutelen. "De wachtwoorden waren wel gecodeerd, maar niet gesalt. De kans bestaat dus dat het te decoderen is", aldus Pieter-Paul Tersmette van Mapp tegen Tweakers.

De webwinkelketen heeft zelf klanten op de hoogte gesteld van de digitale diefstal via een mail. Klanten kunnen pas weer wat bestellen als zij met de link uit de mail een nieuw wachtwoord hebben ingesteld. Mapp is de eigenaar van webwinkels als InternGeheugen.com, Geheugen.nl en Harddisk.nl. Het gaat om gegevens van 157.000 klanten. "Daar zitten ook veel klanten bij die jaren geleden voor het laatst iets hebben besteld, dus veel van de mails komen terug, omdat het mailadres al niet meer bestaat." Andere gegevens, zoals adres en betalingsgegevens, zijn niet gestolen.

De dief of dieven konden de database in via een sql-injection, zegt Tersmette. "We hebben de hele nacht doorgewerkt om het lek te dichten en de beveiliging te verbeteren." Naast het dichten van het lek beveiligt de webwinkelketen wachtwoorden nu beter. "Dat doen we nu met een 256bits sha2-codering met dubbele salt, dus dat zal een stuk veiliger moeten zijn."

Reacties (102)

[mOTiVe]

Misschien leuk om een compleet overzicht van de webshops te geven?

AccuDienst.nl
MotorAccus.nl
InternGeheugen.com
Geheugen.nl
MemoryMan.nl
Harddisk.nl
PhoneStore.nl
RadioSjaak.nl
DashcamStore.nl
GPSTrackerShop.nl
VerpakkingStore.nl

[The Zep Man]

Zo zie je maar weer, bij bedrijven die de onderkant van de markt bedienen het snel fout gaat.

Van Security.nl

Onder Mapp.nl, dat in 2001 als interngeheugen.com begon(...)

14 jaar is niet snel. Dat maakt het overigens niet minder slordig.

Welke compensatie wordt er aangeboden aan de slachtoffers? Is er al aangifte gedaan tegen het wanbeleid van Mapp? Alles valt te hacken, maar persoonsgegevens van je klanten verliezen door SQL injecties moet gezien worden als computervredebreuk vanuit de daders en als nalatigheid van de webwinkel. Vanuit redelijkheid en billijkheid is dit niet te verantwoorden.

[Reactie gewijzigd door The Zep Man op 26 juli 2024 23:25]

[Dutch_CroniC]

Compensatie? dat is voor het eerst dat ik dat iemand hoor roepen na een hack..
Staat trouwens duidelijk bij dat NAW gegevens niet gestolen zijn.

[The Zep Man]

Compensatie? dat is voor het eerst dat ik dat iemand hoor roepen na een hack..
Staat trouwens duidelijk bij dat NAW gegevens niet gestolen zijn.

Wel niet-gesalte wachtwoorden. Combineer dat met een verkregen e-mailadres en even indexeren via rainbow tables en je hebt veel schade omdat de meeste mensen hetzelfde wachtwoord en e-mail adres gebruiken voor verschillende diensten.

[Reactie gewijzigd door The Zep Man op 26 juli 2024 23:25]

[Dutch_CroniC]

Dus niet-gesalte wachtwoorden vallen bij jou onder NAW gegevens?

"Alles valt te hacken, maar persoonsgegevens van je klanten verliezen door SQL injecties moet gezien worden als computervredebreuk vanuit de daders en als nalatigheid van de webwinkel"

Staat toch duidelijk in het artikel dat er geen NAW gegevens gestolen zijn, dus snap niet waarom je dat aanhaalt icm een compensatie.

[The Zep Man]

Dus niet-gesalte wachtwoorden vallen bij jou onder NAW gegevens?

Waar schrijf ik dat?

E-mailadressen vallen onder persoonsgegevens, en kunnen gecombineerd met een wachtwoord (dat beschikbaar is) gebruikt worden om meer gegevens buit te maken.

[Dutch_CroniC]

Ha ja sorry. Ik verwar persoonsgegevens met NAW gegevens.
Maar ben het niet met je eens dat een email adres onder persoonsgegevens valt. Hoewel het tegenwoordig lastiger is om anoniem een account aan te maken ergens.

Kan wel zijn dat een e-adres onder persoonsgegevens vallen maar zo zie ik dat zelf niet.

[Reactie gewijzigd door Dutch_CroniC op 26 juli 2024 23:25]

[windwarrior]

Arnoud Engelfriet is hier op zijn blog duidelijk over, een email-adres is een persoonsgegeven.

http://www.iusmentis.com/...privacy/persoonsgegevens/

[Romaap]

Buitgemaakte persoonsgegevens is in deze situatie ook niet het ergste.
Wat ik het ergste vind is het feit dat de wachtwoorden die buitgemaakt zijn niet gesalt zijn, dat hoort de dag van vandaag gewoon niet meer. Ik geloof niet dat ze in al die jaren geen tijd hebben gehad om zo'n cruciale Security flaw te fixen.

[lv0]

ik zou liever gehad hebben dat ze m'n adres hadden i.p.v. mijn email en wachtwoord.

Bovendien is dat het 1e wat ze veranderen bij dit of een ander account dat door dit gehackt wordt en bestellingen worden gedaan.

[Reactie gewijzigd door lv0 op 26 juli 2024 23:25]

[Verwijderd]

ik snap ook niet wat gecompenseerd moet worden. compensatie voor wachtwoorden die misschien ook gebruikt wordt bij ik weet niet wat en hiervoor compenseren? een beetje ver gezocht.
Wat moeten de hackers nou weer met wachtwoorden van vage webshops?

[StarZ]

Tja, ondanks dat ik het slordig vind van de webshop moet je je als consument ook 3x afvragen welke gegevens je waar achter laat met welk wachtwoord. Stukje bewustzijn lijkt me.

[AMS76]

Dat is dan hun eigen domme schuld, uiteraard. Nooit overal hetzelfde wachtwoord gebruiken. Je kunt er donderop op zeggen dat er ooit ergens een dienst waar je gebruik van maakt gehacked wordt... En dan misschien je password ook achterhaald.

[trisje]

Ergens heeft hij wel gelijk. Het is gewoon slecht beveiligd en on de verantwoordelijkheid maar bij de consument te leggen vind ik ook idioot.
Ze kunnen het blijkbaar wel want naar de hack hebben ze alles keurig op orde. Inclusief gesalte paswoorden.

[RGAT]

Tja dan is er ineens budget en wil vanuit management om beveiliging aan te pakken
Hoewel als ik systeembeheerder zou zijn ik niet zou kunnen slapen als mijn systeem gevoelig is voor iets kinderlijk simpels als SQL injectie, ik zou me rot schamen

[WillySis]

Met gebruikersnaam en wachtwoord kan je inloggen en je gegevens veranderen. de NAW gegevens zijn dus eenvoudig te achterhalen.

De sql injectie is al een oude kwetsbaarheid en eigenlijk mag dat niet meer voorkomen. Mapp mag zeker verantwoordelijk worden gehouden voor misbruik van je account, maar een standaard schadevergoeding bestaat hiervoor in Nederland niet. Alleen als je schade ondervindt kan je proberen die te verhalen. De schade die je vanaf nu oploopt kan je voorkomen en de kans dat je die kunt verhalen is minimaal. Je zal dus snel het wachtwoord op alle sites waar je dat ook gebruikt moeten aanpassen.

De wet mag overigens wel eens worden aangepast, zodat de aansprakelijkheid voor een slechte beveiliging geregeld wordt, aangevuld met een meldplicht aan de (mogelijk) betrokken personen. Een ongebruikt account dient na een x aantal jaar te vervallen. Nu blijft men maar verzamelen.

[eL_Jay]

Inderdaad, ik wacht dan ook op de eerste Nederlandse rechtzaak waarbij een bedrijf een ander bedrijf een proces aandoet voor dergelijke grove nalatigheid.

Wellicht dat er daarna eens aan de burger wordt gedacht. Allemaal leuk en aardig dat de overheid zich in allerlei gekke bochten moet springen om aan de (te) vergaande privacy wetgeving in Nederland, maar ondertussen hebben bedrijven er gewoon lak aan.

Liever zie ik dat de overheid meer speelruimte krijgt, maar de speelruimte van het bedrijfsveld GROF wordt ingeperkt. Ikzelf maak me niet zo druk om het feit dat de overheid bij gegronde verdenkingen volledige toegang heeft tot mijn data. Wel aan bedrijven die mijn gevoelige data op straat gooien (al dan niet bewust* of niet).

Dergelijke grove nalatigheid is imo bewust. (kosten snijden)

[Reactie gewijzigd door eL_Jay op 26 juli 2024 23:25]

[Verwijderd]

Ikzelf maak me niet zo druk om het feit dat de overheid bij gegronde verdenkingen volledige toegang heeft tot mijn data.

Tot dat je bedenkt dat de overheid achteraf gezien ALTIJD gegronde verdenkingen heeft, zelfs wanneer iemand onschuldig is (zie zaak-Kowsoleea en zaak-Ehigiene). Mensen die door de molen van de overheid worden gehaald waarvan later blijkt dat ze onschuldig zijn, krijgen geen of minimale compensatie want de overheid was in de veronderstelling dat de verdenkingen gegrond waren. Dus als jij volledige toegang geeft tot jouw data, welke overigens bij jou thuis wordt opgehaald middels een huiszoeking waarbij ook je badkamertegels vakkundig worden "verplaatst" maar dat is bijzaak, dan draai jij zelf op voor de reparatiekosten want de overheid was in de terechte veronderstelling dat er een gegronde verdenking was.
Bovendien, als je ZZP'er bent en je data wordt in beslag genomen waardoor je geen belastingaangifte meer kunt indienen, orders voor de klanten niet meer kunt afmaken etc, dan moet je zelf maar uitzoeken hoe je jezelf redt en hoe je je gaat verantwoorden naar de klant toe.
Voor iemand die in een dergelijke situatie vrijgesproken wordt geldt: daar is het gat van de deur, geniet van je vrijheid, en we willen niets meer van jou horen. Ook niet over schadevergoedingen.
Kortom, besef wel wat het inhoudt om volledige toegang te geven tot jouw data (vooral als je niets hebt misdaan).

[eL_Jay]

Compensatie regeling en klaar.
Nu nog een compensatieregeling voor deze gedupeerden klanten.............. ow wacht.

[Verwijderd]

Compensatie regeling en klaar.

Compensatieregeling bij de overheid is niet zo makkelijk.
1. Bij compensatie moet er schuld kunnen worden aangetoond. In jouw fictieve geval heeft de overheid geen schuld, want de overheid is terecht in de veronderstelling dat er gegronde verdenkingen zijn.
2. Indien er wel een compensatieregeling is, dan zijn er allerlei regels die de overheid hanteert waardoor de hoogte van die compensatie minder wordt. Zo is er in de zaak-Ehigiene een geleden schade van 2 of 3 ton, maar de overheid was slechts bereid tot het betalen van 30k. Een schijntje dus.

Nu nog een compensatieregeling voor deze gedupeerden klanten

Jah, voor klanten van bedrijven is compensatie wel reëel want bedrijven kunnen officieel ergens schuldig aan zijn.

[telenut]

reken daar maar niet op...
volledige database met persoonlijke gegevens van de NMBS (belgische spoorwegen) was enkele jaren geleden ook zo van het internet te plukken. Nooit vergoeding voor gekregen, zelfs niet op de hoogte gebracht. Heb het zelf moeten ontdekken..

[Verwijderd]

De roep om compensatie is mijns inziens enigszins voorbarig. Het is immers (nog) niet zeker of er schade is geleden en dat is toch minimaal vereist om schade gecompenseerd te krijgen.

[Aardappelkroket]

Jammer dat het eerst fout moet gaan voordat men zijn beveiliging aanscherpt.
Wat is overigens het nut van een dubbele salt?

[Reactie gewijzigd door Aardappelkroket op 26 juli 2024 23:25]

[Upquark]

http://stackoverflow.com/...alt-for-hashing-passwords

[Verwijderd]

TLDR: Dubbel gesalt maakt geen bal uit, maar dat weet het publiek niet. Het lijkt alleen beter te zijn omdat je een beveiliging dubbel toepast.

[Arietje]

Ben ik het toch niet helemaal mee eens. In de link staat

The only way that you'd get any value from this is while the static salt is unknown - the equivalent to the algorithm being unknown. If your binary or your source is available to the attacker, then reverse engineering will demonstrate the algorithm and the hard coded salt.

En dat is dus best een toegevoegde waarde, het is mogelijk dat men alleen de database heeft, en niet de code. Dus een static salt kan prima onderdeel zijn van de verdere trucs die je in de code toepast. Vind dat er wel heel snel gedacht wordt dat ook de code meteen samen met de database op straat ligt.

[M3!]

Een goed hashing algoritme geeft een compleet andere hash bij het wijzigen van ook maar 1 bit. De lengte, of hoeveel salts je toevoegd hebt maakt dan niet heel veel meer uit. Het grote voordeel is dat je minder aan je rainbowtables hebt, én niet gemakkelijk kan zien wie er dezelfde wachtwoorden hebben in de database.

Als je ziet dat er 10 mensen hetzelfde wachtwoord hebben (dezelfde hash), dan ga je natuurlijk eerst die bruteforcen. Een salt per gebruiker zorgt dus dat ook al zijn de wachtwoorden hetzelfde, je toch een andere hash krijgt.
Die salt is meestal random, dus je kan vrij gemakkelijk zien waar de salt begint en eindigt bij de meeste wachtwoorden (@#$[e-mail] bijvoorbeeld).

[Arietje]

Het voordeel van de 'pepper' (dat is de static salt), is er wel degelijk. Puur om bruteforce (optioneel +dictionary) tegen te gaan. Als je pepper uit 1 karakter (1) bestaat, en je wachtwoord is password krijg je slechts password1(+salt, maar die staat dan netjes in de database). Dan heb je password1 dus alsnog vrij snel te pakken. Ga je echter voor een lange pepper, dan is dat eigenlijk niet meer te doen. Een ander en of extra manier is om die hash, nog eens te encrypten met bijv. AES in je applicatie. Het gaat er in ieder geval om dat je behalve een simpele hash&salt in de applicatie nog extra dingen doet. En dan ook nog proberen om je applicatie of dat gedeelte te verstoppen. Zoveel mogelijk lagen, als je het minimale doet en vervolgens gaat roepen dat het allemaal verder niet uit maakt omdat ze alles toch dan wel hebben, dan gooi je de handdoek wel heel snel in de ring.

[M3!]

Daar heb je absoluut gelijk in, maar ze hebben het niet over een pepper, maar over meerdere salts. Dat kan natuurlijk een lomp foutje zijn van hun woordvoerder, maar getuige de staat van hun applicatie (en de keuze voor 'een sha2' algo anno 2015) verteld wel meer...
Facebook gebruikt bijvoorbeeld ook meerdere lagen, ze noemen het zelfs 'The onion'

[Aardappelkroket]

Daar dacht ik dus ook aan inderdaad..

[92458-37017-EB]

Het maakt een hash nog moeilijker te decrypten.

[eL-Prova]

Dat is afhankelijk van soort hash! De kracht ligt niet zozeer meer in hashes en de encryptie maar juist hoe je dit faciliteert. Denk hierbij aan na iedere inlogpoging de tijd met 0.5 sec te verlengen waardoor het langer duurt voor je resultaat krijgt (op bruteforce bijvoorbeeld)

On topic. Ik verbaas me zo ontzettend dat ondanks dat SQL injection al zo lang en breed bekend begrip is. Er nog programmeurs zijn die toch plain input in SQL stoppen.

[.oisyn]

Denk hierbij aan na iedere inlogpoging de tijd met 0.5 sec te verlengen waardoor het langer duurt voor je resultaat krijgt (op bruteforce bijvoorbeeld)

Dat is hier niet echt bijzonder relevant.
1. Als je brute force wilt inbreken door simpelweg de normale loginprocedure te gebruiken, dan boeit het niet hoe wachtwoorden intern zijn opgeslagen.
2. Anderzijds, als je toegang hebt tot een database met wachtwoorden, zoals hier het geval is, dan gebruik je het hele loginscherm niet en kun je alle computing power die je tot je beschikking hebt inzetten om de hashes te reversen. Een timer en counter op inlogpogingen gaan daar helemaal niets aan veranderen.

[Reactie gewijzigd door .oisyn op 26 juli 2024 23:25]

[eL-Prova]

Correct, waar mij om ging is dat dubbel hashen uiteindelijk niets uit maakt.
Maar verlengen van inlogtijd per inlogpoging maakt drempel wel hoger om van buitenaf via bruteforce in te breken

[Verwijderd]

Het is dan in alle opzichten beter om die verlenging intrinsiek in het hashen zelf te stoppen (door een hele zware KDF te gebruiken zoals PBKDF2 of scrypt of bcrypt), dan om geforceerd een sleep er tussendoor te gooien die iemand met toegang tot de database simpelweg kan negeren.

[92458-37017-EB]

Iedere inlogpoging verlengen had hier niets uitgemaakt omdat ze rechtstreeks bij de database konden door de SQL-injectie. Als je de hashes eenmaal hebt is het een kwestie van rainbow tables en wachten.
Als je echt goede security wil moet het verhaal aan alle kanten waterdicht zijn.

[eL-Prova]

Wat je inderdaad terecht aangeeft, SQL-injectie in combi maakt het sowieso een lek mandje. Mijn reactie is ook meer gericht op het argument dat men wel eens geeft "Ik ga dubbel hashen".

[92458-37017-EB]

Helemaal mee eens. In principe zou je het altijd moeten beschouwen als een kwestie van tijd totdat je hashes gebroken worden als je deze in de verkeerde handen komen. Het feit is gewoon dat een voldoende grote set hashes die ontstaan uit door mensen gekozen wachtwoorden met genoeg rekenkracht altijd te herleiden is tot die wachtwoorden.

[Verwijderd]

Een hash decrypten

Een hash is een one-way operatie, en encrypt niets, dus er valt niets te decrypten.

[92458-37017-EB]

Sorry, de juiste term is natuurlijk 'cracken'.

[R4gnax]

Sorry, de juiste term is natuurlijk 'cracken'.

De juiste terminologie in het geval van een hash is het vinden van een 'collision'...

[Reactie gewijzigd door R4gnax op 26 juli 2024 23:25]

[kalekip1]

Kraken. Een hash is niet reversable. Anders is het een encryptie: je kunt het decrypten.

Dus:
Hash = crackable (bijv. door bruteforce)
Encryption = decryptable

[Verwijderd]

de wachtwoorden konden misschien al goed beveiligd geweest zijn. de sql inject is natuurlijk een "domme" programmeerfout, en zolang niemand van de testers of programmeurs dit ontdekt gaat niemand dit zelfs weten. heel leuk dat er iemand dit lek heeft gevonden, minder leuk dat ze er meteen misbruik van hebben gemaakt.

[NESFreak]

Dat doen we nu met een 256bits sha2-codering met dubbele salt, dus dat zal een stuk veiliger moeten zijn.

Het moet ook eerst misgaan voordat het gefikst wordt....

[Kaastosti]

Ja best kwalijk... helaas werkt het nog steeds zo. Het gaat om een systeem wat compleet buiten onze controle ligt, wat kun je er als consument aan doen om de impact van zo'n hack voor jezelf te minimaliseren?

[Quas]

Bij Gmail kan je unieke email adressen aanmaken. Bijvoorbeeld [e-mail] dan komt het gewoon bij jou binnen. Als je dan ook nog een uniek wachtwoord gebruikt dan loop je helemaal geen risico. Als betaal methode kan je het beste paypall gebruiken dan loop je ook geen risico.

[raro007]

Dus als ik mij voor een site moet registreren maar niet mijn echte email adres wil geven kan ik een unieke email adres maken?
hoe doe je dat?
is best wel handig dan.

[Quas]

He hoeft er niks voor te doen. Als je ergens [e-mail] invult komt het binnen op [e-mail]
Hoe makkelijk wil je het hebben

[Verwijderd]

Typische aanrader daarvoor: dispostable.com

Je kunt ergens direct [e-mail] invullen als email-adres, zonder dat eerst te hoeven registreren of bij dispostable.com te moeten inloggen.

[Kaastosti]

Dat werkt natuurlijk alleen als de ontvangende partij dat soort karakters accepteert in een mail adres, wat in het geval van een + nog maar de vraag is. Als hackers een lijst mail adressen hebben, vermoed ik dat ze +ietsanders toevoegingen er ook zonder problemen af kunnen halen

Unieke wachtwoorden worden dan inderdaad weer relevant, zo kun je de impact inderdaad nog beperken. Gaan we er natuurlijk wel van uit dat de partij die de wachtwoorden opslaat dit netjes encrypted doet en niet in plain text. Want ja, zelfs dat wordt nog gedaan.

Paypal moet ik echt niks van hebben, maar da's persoonlijk natuurlijk. Heb 't in ieder geval nog nooit nodig gehad.

[Verwijderd]

puntjes zijn variable binnen gmail. Ik maak er zelf enorm veel gebruik van tijdens het testen van registratiesystemen voor mijn werk.

[e-mail]
[e-mail]
[e-mail]

komen allemaal op hetzelfde adres binnen.

Bij welke tekens het nog meer werkt durf ik zo 123 niet te zeggen, maar "." is algemeen geaccepteerd binnen mailadressen.

[Verwijderd]

Hehe gebruik ik ook veel voor te testen

Overigens verbazend hoe weinig mensen hiervan op de hoogte zijn.
Ook als je je email adres geeft en op de bijna immer aanwezige vraag
"met een puntje tussen <voornaam> <achternaam> ?" antwoord "zoveel puntjes waar je maar wil" krijg ik veelal ongeloof als antwoord terug

[Intrepidity]

Niet helemaal waar, meerdere punten achter elkaar kunnen in ieder geval niet

"Character . (dot, period, full stop) (ASCII: 46) provided that it is not the first or last character, and provided also that it does not appear consecutively (e.g. [e-mail] is not allowed)."

[Verwijderd]

Ah thanks, je hebt gelijk .. echter .. van gmail naar gmail gaat dit echter wel (vanuit de webinterface toch, kan zijn dat je mail client het er wel moeilijk mee heeft)

[telenut]

helaas zijn er nogal veel sites die een + niet aanvaarden in een email adres

[Verwijderd]

Helaas ja, ten onrechte want dat is gewoon 100% valide volgens de RFC standaard. Typisch gevalletje van eigenwijze programmeur die zelf wel even een 'slimme' (not really...) regular expression in elkaar flanst om email-addressen te checken.

[kalekip1]

Een e-mail kan zo gevarieerd zijn dat één RegEx nooit helemaal goed is. Gewoon checken voor een apenstaartje.

[garriej]

Overal verschillende wachtwoorden gebruiken... Meer kun je niet als de systemen buiten je eigen beheer liggen.

Misschien een speciaal e-mail adress dat je gebruikt om online mee te shoppen...? ik heb werkelijkwaar geen flauw idee.

[Reactie gewijzigd door garriej op 26 juli 2024 23:25]

[Verwijderd]

Als je een eigen domein hebt kun je in principe alle e-mail adressen automatisch open zetten, en dan intern doorzetten naar een enkel adres.

Voorbeeld, je hebt persoonlijk.nl als domein. Je eigen adres is [e-mail]

Maar dan wil je wat gaan kopen bij de MediaMarkt online. Als e-mail adres voer je [e-mail] in. Je server vangt alles af, en je krijg het mailtje gewoon op je [e-mail] binnen.

Voor tweakers voer je tijdens het registreren [e-mail] in, en voor bol.com [e-mail]

Op die manier verspreid je je persoonlijk mailadres niet, en áls er spam binnenkomt kun je direct aan het mail adres zien wie van de partijen onzorgvuldig met je gegevens omgaat.

Zitten natuurlijk ook weer nadelen achter, maar het is een mogelijkheid.

[kalekip1]

Spaaaaam.

Heb je het zelf geprobeerd? Valt de spam mee?

[Verwijderd]

Nee, zelf nooit uitgeprobeerd. Wel klasgenoten gehad die zo werkten en die waren er over het algemeen behoorlijk tevreden over.

[92458-37017-EB]

Gebruik een passwordmanager die per site een willekeurig cryptografisch sterk wachtwoord gebruikt. Zelfs als er eentje 'compromised' is er geen gevaar voor andere accounts.

Daarnaast gebruik ik zelf een aliasaccount voor de meeste sites die vinden dat ze mijn naam, adres, woonplaats, geboortedatum, werkveld, lievelingskleur, telefoonnummer, faxnummer, relatiestatus, persoonlijke slogan en weet ik veel wat allemaal nog meer nodig hebben voordat ik een account mag maken. Als het niet strikt noodzakelijk is voor mijn gebruik van de website krijg je mijn echte gegevens niet.

[CyBeR]

Waarbij 't nog steeds niet écht gefixt is want hoewel een sha2 niet zomaar teruggerekend gaat worden (en een rainbow tabel ook nog onpraktisch is), is dat nog steeds niet echt de beste manier om een wachtwoord op te slaan. Daarbij denk ik dan toch aan een PBKDF2 of bcrypt met een groot aantal rounds.

[Martijn_1998]

Inderdaad, ik zou inderdaad bcrypt of dergelijke gebruiken zodat je tenminste écht bij bent.

[rolandverh]

Toch wel jammer dat een onderneming met een kleine 12 webwinkels en 157k klanten er niet continue bovenop zit om servers met dit soort informatie beter te beveiligen. Waarschijnlijk (ik neem even iets aan) was de diefstal eenvoudig te voorkomen geweest door up-to-date houden van de software en zorgen dat beveiliging van servers minimaal iedere maand wordt bekeken en eventueel aangepast.
Dan zijn er ook de klanten die op veel verschillende sites dezelfde wachtwoorden gebruiken. Die mensen vragen er een beetje om dat ze nu op allerlei andere sites iets moeten doen.
Hulde voor de eigenaar van de site dat ie direkt met de billen bloot gaat! Deze 'fout' zal hij niet meer maken.

[92458-37017-EB]

Het meest waarschijnlijke antwoord is dat het uitvoeren van een serieuze penetratietest nooit enige prioriteit heeft gehad voor de onderneming. Er zal ongetwijfeld zijn nagedacht over de beveiliging, maar waarschijnlijk slechts in een abstracte zin.

[Verwijderd]

Hulde aan de eigenaar om met de billen bloot te gaan, akkoord ... maar anderzijds aan de schandpaal met die eigenaar om in deze tijd a) SQL injectie niet te voorkomen en b) geen deftige paswoord hashing met een goede random salt te gebruiken ... had zelfs enkele jaren geleden al niet meer mogen voorkomen, laat staan nu.

[kalekip1]

"Dat doen we nu met een 256bits sha2-codering met dubbele salt, dus dat zal een stuk veiliger moeten zijn."

Hij weet het niet eens zeker. Wat ben je dan?..

Ze moeten gewoon Bcrypt gebruiken: super simpel, want voor zowat elke programmeertaal is er ten minste één library.

[Reactie gewijzigd door kalekip1 op 26 juli 2024 23:25]

[Bosmonster]

Op zich niet zo gek, als ik deze vacaturetekst lees:

Samen met onze programmeur ben je verantwoordelijk voor nieuwe ontwikkelingen op onze webwinkels.

Ze hebben maar 1 programmeur developer in dienst

[mashell]

Hoeveel developers heeft een webshop nodig?

[Verwijderd]

Een database specialist (databases worden snel langzaam wanneer je niet weet hoe je moet optimaliseren), een backend specialist, een frontend specialist, serverbeheerder etc. Er zijn veel taken, en een beetje webshop vraagt gewoon full time aandacht.

Een goede webshop is bijvoorbeeld ook altijd in ontwikkeling en zal nooit stil staan.

[Bosmonster]

Met 12 websites? Toch redelijk team zou je zeggen.

Coolblue heeft er rond de 100.

[garriej]

"Dat doen we nu met een 256bits sha2-codering met dubbele salt, dus dat zal een stuk veiliger moeten zijn."

Dat hebben ze in een dag weten te migreren, waarom hebben ze het dan niet eerder gedaan.

En owja: SQL-injection, really?

[Verwijderd]

Dat dacht ik dus ook, hoezo via een SQL injection? Dat is een van de eerste dingen die je als programmeur leert, hoe sql injections te voorkomen.

Hoewel er wel trucjes zijn om er alsnog doorheen te komen zijn ze over het algemeen al gepatched of niet algemeen bekend.

[Verwijderd]

Bij de meeste organisaties krijg je simpelweg niet de tijd om pro-actief achter dit soort zaken aan te gaan.

Zo heb ik zelf ook eens gewerkt met een project, die zeer eenvoudig te kraken was, waarmee de database geheel uit te lezen was.
Het probleem was (ik heb het project trouwens niet opgezet en kende de exploit niet).. dat ik een paar uur had voor een bepaalde toevoeging.
Ik kreeg niet zoveel % de tijd om zelf achter zaken aan te gaan.
Het is zelfs zo.. als ik zelf had besloten.. meh.. laat ik het eens onderzoeken.
- "Waarom ben je niet met X en X bezig!?" (in deze context werd mijn leidinggevende letterlijk boos)

Hier kwam uiteindelijk een jongetje van Bits of Freedom achter, die meteen allerlei dreigingen uitte en zichzelf probeerde te verrijken.
Die Christelijke moraalridder was vrij snel stil, toen hij zelf werd bedreigd met een rechtzaak.
Hij had verder gelijk en het was goed om te melden, maar je moet niet vanuit zelf verrijking lopen dreigen.
(iedereen is verder meteen op de hoogte gesteld ook, waardoor iedereen zich tegen de jongen van Bits of Freedom keerde)

Toen hij ook nog boos werd, omdat we op zijn naam hebben lopen zoeken, was het voor mij op met Bits of Freedom.

Het was in de context van..
- "Jullie gaan het nu oplossen en anders ga ik met gegevens naar die en die"
- "Bedankt, we hebben het opgelost, alle partijen weten het. Stap met de gegevens naar een ander en we klagen je aan"

(de gegevens waren zeker privacy gevoelig, maar niet financieel interessant)

Deze exploit was trouwens nog erger dan een SQL injection. (welke volgens mij ook mogelijk was)

[MrRobot]

Ik heb een mailtje gehad van Mapp met daarin hun verklaring en excuus:

Beste heer/mevrouw klant,

Gisteren hebben wij moeten constateren dat een deel van ons klantenbestand is gestolen. Hierbij gaat het om emailadressen en gecodeerde wachtwoorden, die zijn opgegeven bij bestellingen in onze webwinkels.
Alhoewel de gestolen wachtwoorden gecodeerd zijn, hebben we toch uit veiligheid direct alle wachtwoorden van al onze klanten uit onze systemen verwijderd. Uw account is nu gedeactiveerd en blijft gedeactiveerd totdat er een nieuw wachtwoord is aangemaakt.
U kunt hier automatisch een nieuw wachtwoord aanmaken.
Belangrijk:
Als u uw oude wachtwoord, al dan niet in combinatie met uw emailadres, ook op andere plekken heeft gebruikt, bijvoorbeeld bij andere webwinkels, op Facebook, (web)mail of Marktplaats, dan adviseren wij u dit meteen te wijzigen.

Onderzoek:
Na de eerste melding zijn we direct met man en macht aan de gang gegaan om te onderzoeken hoe onze klantgegevens in handen van derden konden komen. Inmiddels is duidelijk geworden hoe dit heeft kunnen gebeuren en is het lek onmiddellijk gedicht. Van de diefstaf zal aangifte gedaan worden bij de politie.

Uw veiligheid:
Wij doen er alles aan om de veiligheid van uw gegevens te kunnen waarborgen. De diefstal van onze klantgegevens is helaas niet meer terug te draaien. Maar, naar aanleiding daarvan hebben wij diverse testen en controles laten uitvoeren en onze webwinkels zijn veilig. Wij zijn er van overtuigd dat u veilig kunt winkelen bij ons.

Wij bieden u onze excuses aan voor het ontstane ongemak. Wij betreuren het dat u en wij slachtoffer zijn geworden van kwaadwillende mensen.

Heeft u naar aanleiding van deze email vragen, dan kunt u te allen tijde contact met ons opnemen.

Met vriendelijke groet,

Pieter-Paul Tersmette
MAPP
http://www.mapp.nl/

Ik heb alleen nooit iets besteld bij 1 van hun shops (voor zover ik weet).

Edit: Na het wijzigen van mij wachtwoord zie ik dat het om Hardeschijven.com ging, ik heb hier in 2004! iets besteld. Ik weet niet zeker of ik toen al verschillende wachtwoorden gebruikte voor websites.....

[Reactie gewijzigd door MrRobot op 26 juli 2024 23:25]

[Skizzik0]

Ik heb een mailtje gehad van Mapp met daarin hun verklaring en excuus:


[...]


Ik heb alleen nooit iets besteld bij 1 van hun shops (voor zover ik weet).

Edit: Na het wijzigen van mij wachtwoord zie ik dat het om Hardeschijven.com ging, ik heb hier in 2004! iets besteld. Ik weet niet zeker of ik toen al verschillende wachtwoorden gebruikte voor websites.....

Ik kon me ook niet meer herinneren daar ooit te iets hebben besteld, bleek dat ik er ~4 jaar geleden een microSD kaartje had gehaald. Als je de link in de email volgt krijg je een nieuw wachtwoord gestuurd en kun je inloggen om al je oude facturen in te zien.
Jammer, achteraf had ik liever 'n Euro meer betaald voor m'n kaartje aan een partij die onze persoonsgegevens wél serieus neemt.

[leoBO]

Zo ook mijn gegevens zijn gestolen bij MAPP.

Zojuist een e-mail gekregen van E-Bay dat er geprobeerd was in te loggen door een niet-geautoriseerde gebruiker. Kennelijk hebben ze mijn wachtwoord van MAPP al gedecodeerd. Hoewel ik niet oneindig verschillende wachtwoorden heb, was die van e-bay kennelijk anders. (laatste keer ingelogd in 2010 of zo).

Een domme vraag misschien, maar wat zijn belangrijke webwinkels die ik misschien vergeet waar op de pof gekocht kan worden?

[Soldaatje]

Paypal.
Daarnaast: gebruik een wachtwoordbeheerder (keepass2), zou eigenlijk verplicht moeten zijn voor iedereen!

[Ample Energy]

Jammer dat het anno 2015 nog niet gesalt was, maar gelukkig hebben ze het lek direct gedicht en de wachtwoorden gereset en iedereen op de hoogte gesteld.
Iedereen kan fouten maken, het gaat er om hoe je het oplost.

Alleen dit:
"Klanten kunnen pas weer wat bestellen als zij met de link uit de mail een nieuw wachtwoord hebben ingesteld."
Is natuurlijk niet de manier... Het ging de hackers waarschijnlijk om de emailadressen en als je geen SPF-records hebt wordt er nu spam verstuurd in jouw naam. Door ook zelf links te gaan sturen in plaats van men er aan te herinneren dat ze nooit op een link in een mail moeten klikken help je niemand.

[92458-37017-EB]

Én niet controleren op SOL-injecties én je wachtwoorden niet veilig opslaan. Prutswerk van de hoogste klasse.