Klantgegevens van ServerKast.com en PatchKast.nl zijn buitgemaakt bij hack

DSIT, moederbedrijf van webshops als ServerKast.com, UTP-Kabel.nl en PatchKast.nl, zegt slachtoffer te zijn geweest van een hack waarbij onder meer naw-gegevens en versleutelde wachtwoorden zijn buitgemaakt. 'Inactieve' accountwachtwoorden zijn met MD5 gehasht.

Het datalek was op 6 april, maar op dinsdag zeggen meerdere tweakers in een GoT-topic een mail van het webshopbedrijf te hebben ontvangen. In die mail geeft DSIT aan dat er na een hack ongeoorloofde toegang is geweest tot klantgegevens. 'Mogelijk' zijn hierbij gegevens gestolen. In het forumtopic zeggen tweakers sinds medio april phishingmails te ontvangen die gericht zijn aan mailadressen die voor DSIT-webshops zijn gebruikt. Het gaat onder meer om betalingsverzoeken die ogenschijnlijk in naam van DSIT-webshops zijn verzonden.

Onder DSIT vallen ServerKast.com, PatchKast.nl, PatchKast.com, PatchKast.be, UTP-Kabel.nl en Glasvezel-kabel.com. Het is niet bekend of alle webshops door de hack zijn getroffen en van hoeveel klanten er data is gestolen, Tweakers heeft hierover vragen gesteld. Onder de mogelijk gelekte data vallen naam en bedrijfsnaam, eventuele btw-nummers, e-mailadressen, telefoonnummers en ordergegevens zoals producten en aantallen. Betaalgegevens zijn volgens DSIT niet gelekt, omdat die gegevens niet bij de webshops worden geregistreerd.

Bij de aanval zijn mogelijk ook wachtwoorden gelekt. Deze waren versleuteld, afhankelijk van de activiteit was dit met een SHA- of een MD5-hash. Oude wachtwoorden van inactieve accounts zijn met MD5 gehasht, waarbij er sprake is van een korte of lange salt, afhankelijk van het wachtwoord. Waarvan een korte of lange salt afhankelijk is, is niet duidelijk. 'Recente' accounts zijn met SHA256 of SHA512 gehasht, beide met lange salt van minimaal 32 karakters. Bij het inloggen van een account wordt het wachtwoord standaard naar de laatste hashmethode bijgewerkt. DSIT geeft geen data over wanneer een gebruiker ingelogd zou moeten zijn om een met SHA gehasht wachtwoord te krijgen.

DSIT zegt het datalek te hebben gemeld bij de Autoriteit Persoonsgegevens, zoals verplicht is in dergelijke gevallen. Verder zegt het bedrijf 'een groot deel' van de phishingmails tegen te hebben gehouden, is de beveiliging aangescherpt en zijn wachtwoorden aangepast.

Reacties (117)

[marcel_76]

Ik heb ook een mail ontvangen en inderdaad al een tijd geen gebruik gemaakt van de diensten dus niet opnieuw ingelogd. Zal wel even doen en wachtwoord aanpassen, gelukkig overal unieke wachtwoorden maar maakt het nog steeds niet fijn dat je persoons gegevens gestolen zijn.
Zoals de mail aangeeft kan het gaan om:
• NAW-gegevens
• BTW-nummer van zakelijke klanten
• Bestelgegevens
• E-mailadres
• Wachtwoorden (versleuteld)

Wie versleuteld de afgelopen jaren nou wachtwoorden met MD5 dat is al heel veel jaren achterhaald, dus heel erg slecht van een IT bedrijf.

Het valt mij op dat het de laatste tijd een beetje schering en inslag lijkt met allerhande gegevens die buitgemaakt worden. Heel erg leuk dat wij als klanten dan daarvan op de hoogte gesteld worden maar ik mis gewoon verdere acties, onze gegevens liggen nu op straat en bij de volgende webshop gebeurd het gewoon wederom opnieuw. Het komt op mij over dat er geen schrik reactie is waarbij alle overige webshops en overige online systemen met klantgegevens nu kritisch naar eigen systemen, versleuteling etc. gaan kijken of misschien zelfs wel door een professioneel bedrijf pentesten etc. laten uitvoeren.

Krijgt dit bedrijf nu een flinke boete? of hebben we gewoon wederom als burgers pech en zitten we in DeShIT

[Nickkname]

Verder zegt het bedrijf 'een groot deel' van de phishingmails tegen te hebben gehouden

Ehm, je kunt als bedrijf geen phishingmails tegenhouden die uit jouw naam verzonden worden...

Je kunt wel je mailserver goed instellen met SPF e.d. zodat het wat lastiger wordt, maar tegenhouden is onmogelijk.

[Reactie gewijzigd door Nickkname op 22 juli 2024 23:10]

[Zebby]

Waarschijnlijk bedoelt men dat ze DMARC hebben ingericht, en daarmee zal iedere zelf respecterende mailserver bij een SPF/DKIM failure de mail rejecten of in de spam plaatsen. Dat is ongeveer "tegen houden". En gezien ze dat durven te zeggen hebben ze ook zeer waarschijnlijk de rapportages aan staan op de DMARC DNS. Als je weet vanuit welk mail adres ze verzenden kun je dit zelf opzoeken en bevestigen.

[DiaZ_1986]

Heeft dat ook effect wanneer er namens ServerKest.com, UTP-Kabels.nl of PatchKest.nl phishingmails verstuurd wordt?

Want volgens mij is het in deze situatie niet te voorkomen?

[To_Tall]

Beetje bedrijf met meerdere domein namen, zullen al deze domein namen, al worden ze niet gebruikt als mail send address. Deze instellen op de mailserver en inrichten met DMARC.

Alleen zo hou je "controlle" over je eigen domein namen.

[DiaZ_1986]

Ja ok, als de domeinen allemaal in eigen beheer zijn, wordt het inderdaad lastig.

Maar ik bedoel juist domeinnamen die veel lijken op het origineel (zoals ServerKest.com kan ik nu kopen voor +/- €7).

Hoe kan dan een beheerder van ServerKast.com mijn e-mails tegenhouden?

[Carharttguy]

Die beheerder kan dat niet.

[To_Tall]

Dat kunnen ze niet, wat ze wel kunnen is die domein namen op kopen.

Grote bedrijven doen dit al standaard..
leuk voorbeeld is google.com, die hebben ook gooogle.com in beheer. Omdat mensen bij snel typen vaak een o te veel tikken

MS heeft ook een hele lijst met domein namen op heel veel TLD's https://en.everybodywiki.com/List_of_Microsoft_domains

Maar het is net als inbreken.. Als ze binnen willen komen dan lukt dat ze toch wel.. Hoe goed je zelf ook beveiligd tegen dit soort spoofing.. kijk bv naar bank spoofing.. ING.nl kunnen ze niet aankomen.. maar ing.phissing.nl wel..

[Reactie gewijzigd door To_Tall op 22 juli 2024 23:10]

[CAPSLOCK2000]

Dat opkopen van varianten op je eigen domein is een beetje passé. Sinds we de toplevel domains hebben vrijgegeven is het gewoon niet meer te doen.
Het gaat ook niet lekker samen met het uitbesteden van IT dat steeds meer bedrijven doen. Daardoor krijg je ook te maken met de domeinen van de aanbieders en krijg je domeinen als mijnbedrijf.sharepoint.com. Daardoor loopt het aantal mogelijke variaties totaal uit de hand.
Ik adviseer dus om het niet of zo min mogelijk te doen en ik heb die vraag ook al een tijd niet meer gehad.

[To_Tall]

Zo passe is het natuurlijk niet..

Er worden nog dagelijks door bedrijven tientallen domein namen overgenomen of toch nog geregistreerd, niet alleen om een nieuw merkt te lanceren. Maar ook om variaties om dat nieuwe merk heen in te dammen.

Tuurlijk gezien de TLD's groeien wordt het soms ook moeilijker en kostbaarder om je te beschermen.. Maar dat betekend niet dat het niet meer noodzakelijk is om bepaalde URL's toch nog te beschermen tegen typo's en net als google met een extra o heeft gedaan en Microsoft.com ook te benaderen is via Microosoft.com.

Helemaal niets doen is net zoiets als.. Hier inbreker.. de deur is dicht maar je kan hem wel openduwen.

[The Realone]

Onwaar, want de meeste mensen kennen de TLD van het bedrijf waarmee ze zaken doen. Google.com vergissen met Google.com zal veel eerder gebeuren dan Google.xyz. En aangezien Google zaken doet in Nederland is hier Google.nl ook bekend, maar die zal een Nederland niet gauw vergissen met Google.cn. En dit verhaaltje kun je doortrekken voor eigenlijk alle domeinen.

[Oon]

Tenzij het bedrijf alle mogelijke namen die op hun eigen naam lijken geregistreerd heeft niet, nee.

[Nox]

Petskast heb ik legit eens op een ruimtenaam/tekening gezien, die ligt meer voor de hand

[Slonzo]

De mails zijn niet afkomstig van de domeinen van DSIT zelf; zie het forumtopic.
Maar misschien bedoel ze inderdaad dat vanaf die domeinen in ieder geval geen spam kan komen.

[biggydeen2]

Een phishing mail wordt dan ook nooit verstuurd vanuit het originele domein maar door een variant daar op. SPF en DKIM houden alleen mail tegen als er wordt geprobeerd vanuit het originele domein een mail te versturen. Dat komt vooral bij grotere domeinen niet voor.

[Zebby]

Ook al zou dat zo zijn, dat maakt mijn comment niet minder correct. Ik merk ook aan dat ik werk met aannames, want ik heb ze niet gehad.

Oh, en als je een uitspraak zo plat doet, verifieer die dan eerst even. Want een paar dagen geleden heb ik van woningnet een mailtje gehad, of misschien waren ze het niet echt?
spf=fail (google.com: domain of [e-mail] does not designate 185.237.204.70 as permitted sender) smtp.mailfrom=[e-mail];
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=woningnet.nl

[biggydeen2]

Natuurlijk kan dat wel. Met een goed ingerichte mailserver kan iemand anders echt geen mail vanuit het originele domein versturen. Een phishing mail komt daarom ook nooit vanuit het originele domein maar vanaf een niet bestaande variant daar op. En dat kan niemand tegenhouden.

Het gaat om de definitie van " uit jouw naam".Een phishing mail kan wel verzonden worden vanuit jouw naam. Maar dan is het enkel de inhoud van de mail of de naam van de afzender. Maar deze mails worden nooit verzonden vanuit het originele domein (mits de mailservers goed zijn ingericht). Vanuit je daadwerkelijke naam dus. De enige manier om vanuit het originele domein te verzenden is na een hack.

[LemonySnicket]

spf alleen niet nee maar met dkim, dmarc kun je de ontvanger nog veel beter informeren.

[monsieurpinot]

Ik kreeg halverwege april al spam op een uniek adres wat ik gebruikte voor utp-kabel.nl, betrekkelijk laat om hiermee nu pas naar buiten te treden..

[Elxaz]

Heb de mail vandaag ook gehad maar kon me niet herinneren dat ik klant was.
Even alle gegevens opgevraagd, UTP-kabel.nl valt hier dus ook onder. Tevens zag ik dat mijn gegevens 5 jaar oud zijn, lijkt me onnodig lang voor de hooguit €20,- die ik aan utp kabel heb gekocht.

Met allekabels zo'n hack net hebben kunnen ontwijken maar het moest er eens van komen...

[dbzokphp]

Zo te zien waren ze bezig met migratie van MD5 naar SHA-hash. Aangezien het niet mogelijk is om wachtwoorden van MD5 om te zetten naar een SHA-hash, werd waarschijnlijk het wachtwoord met een SHA-hash opgeslagen zodra je opnieuw inlogt. Vandaar dat inactieve accounts nog niet over een SHA-hash beschikten, aangezien deze klanten niet hadden ingelogd.
Wellicht was het beter geweest de wachtwoorden van de inactieve accounts te resetten en de klant in te lichten, zodat deze ook opgeslagen worden met een SHA-hash.

[Reactie gewijzigd door dbzokphp op 22 juli 2024 23:10]

[Groentjuh]

Bij zo'n migratie kun je ervoor kiezen om de md5 hash te hashen met het nieuwe algoritme en door een "hash-type" bij te houden kun je dan achterhalen welke soort hashing voor de controle gedaan dient te worden.

Vervangen na een login werd hier gebruikt, maar dan dienen gebruikers wel in te loggen. Wat kennelijk niet gebeurde. Met de eerder genoemde strategie voorkom je dat, want tijdens zo'n migratie zijn alle bestaande wachtwoorden gelijk weer veiliger gehashed.

[Sorcerer8472]

Op zich heel logisch maar bij een soortgelijke migratie (heel veel jaren geleden) hebben we bij waar ik werk dit ook niet gedaan. Wel hebben we na een jaar inderdaad mensen gedwongen om de resetfunctie te gebruiken en toen zijn alle md5-hashes weggegooid.

[biglia]

Bij zo'n migratie kun je ervoor kiezen om de md5 hash te hashen met het nieuwe algoritme en door een "hash-type" bij te houden kun je dan achterhalen welke soort hashing voor de controle gedaan dient te worden.

Dat is eigenlijk zoals de officiële documentatie van Magento het voorschrijft: https://devdocs.magento.c...g-guide/secy/hashing.html

To avoid compromising older passwords that have been hashed with outdated algorithms like MD5, the current implementation provides a method to upgrade the hash without changing the original password.

Pijnlijk dat ze dan deze strategie niet gevolgd hebben. Wanneer je zulke taken moet uitvoeren, ga je toch altijd op zoek naar documentatie hoe dit best uitgevoerd moet worden. Met een veel gebruikt pakket als Magento, ben je heus niet de enige in de wereld die dit probleem ook heeft.

[rjd22]

Wellicht was het beter geweest de wachtwoorden van de inactieve accounts te resetten en de klant in te lichten, zodat deze ook opgeslagen worden met een SHA-hash.

Software ontwikkelaar hier, eigenlijk zijn er maar 2 manieren om goed met oude wachtwoorden om te gaan. Dat is ze of verwijderen of ze dubbel hashen. Op deze manier zijn ze ook veilig als het om oude accounts gaat.

Omdat md5 wachtwoorden consistente resultaten opleveren is dubbel hashen mogelijk op de volgende manier (voorbeeld in PHP)

$newDatabaseHash = password_hash($oldMd5DatabaseHash, PASSWORD_BCRYPT);

Deze kan je dan gewoon controleren met:

password_verify(md5($rawPassword), $databaseHash);

Op deze manier heb je geen oude md5 wachtwoorden meer in je database. Dit werkt eigenlijk met bijna alle oude hashing strategieën.

[Reactie gewijzigd door rjd22 op 22 juli 2024 23:10]

[rjd22]

Dit is natuurlijk zoals ik aangeeft het beste. Maar als je oude accounts moet migreren die nooit meer inloggen maar mensen niet wilt forceren om wachtwoord te resetten dan is dit een veilig alternatief.

Helaas moeten hebben we als software ontwikkelaars niet de keuze om iedereen wachtwoorden te laten resetten omdat de business het niet wilt.

[Sleepkever]

Dat... is exact wat hij zegt? Beter nog, een correcte migratie stategie waardoor je ze niet eens weg hoef te gooien en klanten hoef lastig te vallen en je het tijdelijk dubbel kan hashen met bcrypt... Minder impact is altijd beter dan gewoon zomaar alle wachtwoorden van je klanten weggooien.

[samtoxie]

Dat is echter niet altijd wenselijk, en naast een kleine extra complexity door waar nodig eerst naar md5 te hashen bereik je er verder niet minder mee. Vanuit een business perspectief is dit veel logischer en in mijn optiek ook makkelijker. Die md5 hashes worden namelijk met bcrypt gehashed (en gesalt) en waar nodig wordt tijdens het inloggen password -> md5 -> bcrypt gedaan.

Eind resultaat is dat je geen rauwe md5 hashes meer in je database hebt, maar dat alles bcrypt is (eventueel met tussenstap naar md5 waar nodig).

[Kees]

Natuurlijk is het wel mogelijk om je MD5 wachtwoorden veiliger te hashen (en dan niet met sha256/sha512 zoals ze gedaan hebben, dat zijn 'snelle' hashing functies, en net zo geschikt voor wachtwoorden als md5).

Wat je doet is een klein beetje metadata erbij opslaan, waarbij je bijvoorbeeld zegt 'dit is een oud md5 wachtwoord', en dan hash je de md5-hash met je nieuwe wachtwoord-hashing-algoritme. Op het moment dat die gebruiker dan weer eens inlogt vergelijk je niet zijn wachtwoord met de nieuwe hash, maar de md5 van zijn wachtwoord. En als dat overeenkomt hash je zijn huidige wachtwoord, slaat dat op als de nieuwe hash en verwijder je het veld met 'dit is een oud md5 wachtwoord'.

En voila, al je md5-hashed wachtwoorden zijn ineens ook veilig opgeslagen.

[Orthodroom]

Dit werkt niet. Dat is precies wat hier namelijk speelt. Wat je moet doen is hierboven al uitgelegd en dat is dubbel hashen. De oude hash gooi je daarna gewoon weg. Wel heb je dus metadata nodig om te weten of je het wachtwoord eerst door md5 moet halen voordat je die nieuwe methode toepast.

[Kees]

Dat is ook wat ik in deze zin probeer uit te leggen: "en dan hash je de md5-hash met je nieuwe wachtwoord-hashing-algoritme". De oude md5hash is dan dubbel gehashed.

[Orthodroom]

Door de zin ''vergelijk je niet zijn wachtwoord met de nieuwe hash, maar de md5 van zijn wachtwoord." dacht ik te begrijpen dat je nog ergens de md5 hash zou bewaren. Dat zou dus niet werken. Ik begrijp nu dat je bedoelt met de md5 van zijn wachtwoord, de op dat moment gegenereerde md5 van zijn wachtwoord.

[samtoxie]

Volgensmij is dat ook waar @Kees op doelde, maar ik raakte ook even in de war bij het einde inderdaad

[Reactie gewijzigd door samtoxie op 22 juli 2024 23:10]

[CurlyMo]

Volgens mij kan het veel simpeler. Gooi alle md5 wachtwoorden weg. Geef mensen die met een username inloggen behorende tot die md5 groep een melding bij een inlogpoging met uitleg:

U bent verplicht uw wachtwoord opnieuw aan te maken aangezien we uw oude wachtwoord (voor de huidige tijd onveilig opgeslagen) uit onze systemen hebben verwijderd.

[Gregoor]

Dit is in de praktijk echter geen wenselijke oplossing.

Want op het moment van conversie van gebruik van MD5 naar SHA256/512 hebben alle bestaande gebruikers namelijk een MD5 wachtwoord. Je oplossing betekent daarmee dat in de praktijk alle bestaande gebruikers een nieuw wachtwoord aan moeten maken wanneer ze inloggen.
Daarmee leg je het ongemak als gevolg van jouw conversie geheel bij je gebruikers.

Dat lijkt me voor zo'n conversie geen wenselijke oplossing.

[thegve]

Als accounts met MD5 zo lang niet hebben ingelogged als ik zou verwachten (jaren), boeit dat totaal niet. "Welkom terug! Om de veiligheid van onze systemen te kunnen garanderen vragen vragen we je om je account opnieuw te activeren en een nieuw wachtwoord te kiezen. Klik op de link in de mail!"
Echt niemand gaat hierdoor weglopen als die al een paar jaar niet meer heeft ingelogged.

Daarmee leg je het ongemak als gevolg van jouw conversie geheel bij je gebruikers.

Nee, je neemt als leverancier verantwoordelijkheid voor de veiligheid van je klantgegevens. Iets als bovenstaande zou mij (toegegeven, als IT'er) als klant meer vertrouwen geven in de leverancier.

[Reactie gewijzigd door thegve op 22 juli 2024 23:10]

[thomas1907]

Je begrijpt hem volgensmij niet.

2012: "Hey laat ik MD5 eens vervangen met wat beters"
>Gaat alle MD5 wachtwoorden verwijderen en de melding toevoegen

Dat zijn op dat moment dus *alle* gebruikers. Zonder dubbel hashen heb je dus nogsteeds alleen MD5 of *alle* gebruikers moeten een nieuw wachtwoord aanmaken.

[Reactie gewijzigd door thomas1907 op 22 juli 2024 23:10]

[thegve]

Ik had het inderdaad nog niet goed genoeg gelezen, las achteraf die opzet, klinkt wel handig inderdaad. Mijn opzet ging overigens uit van 'deprecaten'. In 2012 vervang je het, in 2013 haal je alle oude hashes weg. Maar jouw opzet is nog slimmer.

[Kees]

Dat is veel makkelijker inderdaad, maar niet gebruikersvriendelijk. En met mijn oplossing zijn de wachtwoorden net zo veilig opgeslagen als de nieuwe wachtwoorden en nog gewoon bruikbaar.

[Carharttguy]

Dan begrijp ik nog altijd niet waarom ze in 2020-2021 nog voor SHA-512 kiezen. Bcrypt bestaat toch ook al een tijdje?

[dakathefox]

Ze maken gebruik van Magento 2. Daar zit standaard ondersteuning in voor MD5, SHA256 of Argon
2ID13.

[daniel360gt]

...een hack waarbij onder meer naw-gegevens en versleutelde wachtwoorden zijn buitgemaakt.

Wat ik niet begrijp is dat eigenlijk alleen de wachtwoorden versleuteld worden opgeslagen. Waarom worden bij webshops ook niet de NAW-gegeven versleuteld opgeslagen?

Als consument heb ik veel liever dat na een hack mijn NAW- gegevens veilig zijn, dan mijn wachtwoord (die is overal toch anders).

Vraag van iemand die 0 verstand heeft op dit vlak

[Sleepkever]

Er zit wel een klein verschilletje tussen NAW gegevens en een wachtwoord wat die vraag iets complexer maakt.

Een wachtwoord hoeft nooit meer gedecrypt te worden. Vaak doen we wachtwoorden ook niet encrypten maar hashen, een operatie die fundamenteel maar een kant op werkt. Als er gecontroleerd moet worden of iemand hetzelfde wachtwoord heeft ingevoerd vergelijk je de opgeslagen hash met de hash berekend over het ingevoerde wachtwoord. Zijn die gelijk aan elkaar dan klopt het ingevoerde wachtwoord.

NAW gegevens zijn net even anders, die moeten namelijk na opslag ook nog steeds teruggehaald worden naar het origineel. Dat betekend dat voor het decrypten van die gegevens de decryptie sleutel nog steeds aanwezig moet zijn ergens in de draaiende applicatie.

Individuele velden encrypten kan helpen bij een directe database dump en daarom ook de moeite zijn om te implementeren. Maar dat is al snel het enige waar het tegen beveiligd. SQL injection, misschien, afhankelijk van de decryptie implementatie en of die zo aardig is dat ook alvast te dynamisch te decrypten voor je in de applicatie. Als iemand bij de applicatie instantie kan, kan hij ook de decryptie key vinden op disk of in memory. Via social engineering een wachtwoord van een medewerker bemachtigen en toegang krijgen tot de beheersinterface is misschien nog wel makkelijker.

Ik zie hieronder in de comments dat dit mogelijk gebeurt is via de customer export functionaliteit van Magento. Dus het laatste lijkt hier van toepassing te zijn. Daar kan geen encryptie op welk niveau dan ook wat aan doen.

[Reactie gewijzigd door Sleepkever op 22 juli 2024 23:10]

[Kroesss]

Nou, als je de data versleuteld opslaat, kun je als webshop zelf deze info dus niet meer zien. Dan wordt het volgens mij lastig versturen omdat je de adresgegevens dus niet meer op het pakket kunt zetten.

Als je het namelijk versleuteld op een manier dat het weer ontsleuteld kan worden, is het bij een hack alsnog binnen no-time ontsleuteld.

[Reactie gewijzigd door Kroesss op 22 juli 2024 23:10]

[bigoldie]

Als je het namelijk versleuteld op een manier dat het weer ontsleuteld kan worden, is het bij een hack alsnog binnen no-time ontsleuteld.

Dat is natuurlijk niet volledig waar. Als de data wordt opgeslagen in een database en de hacker heeft alleen toegang tot de database, dan heeft de hacker geen toegang tot de sleutel waarmee de data is versleuteld. bullshit in, bullshit out. Heeft de hacker toegang tot de (web)server waar de sleutel op staat, dan kan de hacker na een beetje knutselen wel de data ontsleutelen.

[Reactie gewijzigd door bigoldie op 22 juli 2024 23:10]

[akaash00]

Dat is inderdaad een goed idee, want soms vind ik de NAW gegevens belangrijker dan dat ene wachtwoord die ik heb aangemaakt. Ik denk dat de meeste webshops dit onderschatten, want ik heb nooit gelezen dat ook iemand de moeite doet om die gegevens te versleutelen bij een webshop.

[Kaoh]

Daar ben ik het inderdaad mee eens. Ik gebruik netjes (al een decenia) unieke wachtwoorden per webshop, en waar mogelijk met tags op mijn mail adres/login. Maar mijn telefoon nummer en thuis adres etc, die blijven zo steeds op straat terecht komen. Dus een target voor fishing/whatsapp/sms/belletjes blijf je wel.
Encrypted opslag per account van de naw moet toch ook niet heel moeilijk zijn. Genereer per account een unieke sleutel voor de encrypted storage die je weer opslaat in een goede password vault oplossing waar alleen je service account retrieve rechten heeft. Dan heeft ie echt wel diep in systemen gezeten als dat niet werkt.

[jrswgtr]

Wachtwoorden worden gehashed en niet versleuteld, als je daaronder verstaat dat het ook weer ontsleuteld kan worden. Een hash werkt 1 kant op en kan daarom niet weer ontsleuteld worden. Je wachtwoord wordt dus als hash opgeslagen in de database en op het moment dat je inlogt wordt je wachtwoord vergeleken met die hash.

Voor NAW gegevens moet het wel mogelijk zijn om ze te ontsleutelen en dan heeft het zoals @Kroesss al zegt weinig zin om ze uberhaupt te versleutelen.

[pieterhi]

ik begrijp dit soort shops niet... prima dat er gesleuteld is aan de beveiliging en dat md5 vervangen wordt naar iets anders, maar waarom niet gewoon vanaf dat moment alle wachtwoorden resetten? Dan kan je met een verse start weer beginnen... nu hadden ze allemaal wachtwoorden opgeslagen met een methode waar ze vanaf wilden... om goede redenen.. alleen jammer dat er toen naar sha512 gegaan is en niet scrypt, bcrypt of iets anders 'traags' ;-)

[Reactie gewijzigd door pieterhi op 22 juli 2024 23:10]

[supersnathan94]

Maar gereset naar wat? Je kunt niet iedereen gaan mailen met een link, want die wil je niet heel erg lang geldig hebben. Daarnaast gaan actieve accounts er ook niet op in waarschijnlijk.

En wat doe je daar dan mee?

Ik snap dat je zo snel mogelijk van je MD5 shizzle af wil. Ik denk dat “ff resetten” echter niet heel goed haalbaar is.

Misschien beter om dan een mail te sturen het wachtwoord aan te passen naar iets anders en je dan de nieuwe methode inzet. Dus dat je actief users naar je site trekt en anders account verwijdert (accounts die niet voor bepaalde datum wijzigen zijn dan poef einde verhaal).

[kaas-schaaf]

Dit is zeker wel mogelijk en nog goed te doen ook, het is alleen niet "handig".

In feite is iedereen die na een periode niet ingelogt is af, en moet de enrollment opnieuw doen. Dit kan je doen via een password reset door bij de volgende inlogpoging de reset feature te triggeren met een melding dat je het wachtwoord moet resetten en de email opnieuw moet valideren. Dit kan prima als er geen wachtwoord is, want dat is in feite wat je moet beschouwen met een MD5 digest als password store. Dit heeft het voordeel dat je de oude gegevens kan behouden. Je kan ook mensen geheel opnieuw enrollen en de accounts blokkeren.

Het is gewoon de vraag hoeveel moeite men hier in wil stoppen en gezien dit een rollover van MD5 is, is voor iedereen die dit na 2010 doet de hoeveelheid moeite gewoon 0 geweest.

[systech2]

Een aardige methode lijkt mij om gebruikers forceren een nieuw wachtwoord in te stellen bij de eerstvolgende log-in poging. De huidige wachtwoorden kunnen dan direct worden gewist. En wanneer de gebruiker probeert in te loggen wordt er een e-mail verzonden met een link om een nieuw wachtwoord in te stellen.

[ari]

Een nieuw wachtwoord instellen is een extra handeling voor de gebruiker, wat vanuit gebruiksvriendelijkheid onwenselijk is. Je kunt namelijk op dat punt ook gewoon het wachtwoord dat de gebruiker getypt heeft met het nieuwe algoritme hashen. Als het er puur om gaat dat het nieuwe algoritme gebruikt wordt, dan is dat een handiger manier dan iedereen dwingen een nieuw wachtwoord te kiezen.

Nadeel is dat je moet wachten totdat iedereen een keer ingelogd heeft. En op basis van het artikel vermoed ik dat deze toko exact deze strategie heeft gekozen. Immers, het gaat volgens het artikel uitsluitend om inactieve accounts. Dus veilig voor regelmatige gebruikers, maar de wachtwoorden van de niet-regelmatige gebruikers liggen wel op straat.

[Beagon]

Wat wij voor onze klanten doen is de hashes veranderen naar een random string die totaal niet lijkt op de hash zoals "ThisPasswordIsInvalidated" en als deze text gevonden word tijden het inloggen een melding geven aan de klant dat ze een nieuw wachtwoord moeten aanvragen omdat we de beveiliging hebben opgeschroeft.

Erg simpel en erg effectief. Hierdoor zorg je ook dat klanten vertrouwen houden en zien dat je ook aan de achterkant zorgt dat hun data veilig is.

[supersnathan94]

fair enough. En dan krijg je gewoon de standaard "ik ben mijn wachtwoord vergeten" flow gok ik?

Ik denk dat dat wel een goede manier is om het te bewerkstelligen, zeker als je er dan ook een mailtje uit doet waarbij je mensen oproept om actief opnieuw in te loggen omdat anders het account verloopt.

Nu nog MD5 hebben is gewoon slordig om eerlijk te zijn.

[Beagon]

Correct, gewoon een linkje in de melding naar de wachtwoord vergeten pagina en binnen een minuut of 2 zijn ze weer up and running in hun account met een geupdaten hash.

[gorgi_19]

Die dummystring is een prima methode, inclusief melding.
Kan je ook gelijk na een jaar alle oude accounts verwijderen; deze hebben immers toch ook geen nut meer conform de AVG.

[supersnathan94]

Ja precies. Maar iig iets wat niet bruikbaar is als wachtwoord en eigenlijk daarna een volledige reset triggert die de user zelf uitvoert.

Alles wat meer dan en jaar niet meer gebruikt is gewoon verwijderen. Factuur administratie is verder (als het goed is) toch niet direct aan account gekoppeld dus dat blijf dan intact. Die heb je namelijk wel nog een aantal jaar nodig.

[Rudie_V]

Je kan accounts met een oude hash ook markeren en zodra zo'n account inlogt direct het account vergrendelen, of het wachtwoord resetten met een automatisch gegenereerd wachtwoord, en een link naar het e-mailadres sturen om een wachtwoord reset uit te laten voeren.

[lenwar]

Dan zou ik eerder zeggen. Wachtwoord hashes verwijderen, eventueel vlaggen als 'wachtwoord weg' dus resetten, en als iemand dan probeert in te loggen met z'n/d'r e-mail adres, dat je dan wordt verwezen naar een reset-procedure (of helemaal niks zeggen, en mensen 'gewoon laten resetten' alsof ze hun wachtwoord vergeten zijn).

[pieterhi]

<< verwijderd van meer van hetzelfde als hier boven gezegd is ;-) >>

[Reactie gewijzigd door pieterhi op 22 juli 2024 23:10]

[bazzi]

naja je zit met je oude legacy qua klanten. Dat is niet heel gebruiksvriendelijk. Zelf zijn we enkele jaren geleden ook overgestapt op een ander algoritme. Hiervoor hadden wij een grace periode van een jaar dat je met de oude hash ook kon inloggen en dat het geconverteerd wordt. Na dat jaar hebben we de oude hashes weggegooid, aangezien ene jaar geen activiteit is geweest. Dan vraag je maar ene nieuw wachtwoord aan. Aangezien het MD5 was, hadden ze dat ook wel 15 jaar geleden mogen doen

[JapyDooge]

Vanuit gebruiksvriendelijkheid is zo'n 'achter de schermen' upgrade van je hash niet ongewoon; al was het beter geweest de MD5 hashes nogmaals naar SHA te hashen ipv als MD5 te blijven bewaren.

[DoctorBazinga]

Eerst mijn account bij alleskabel.nl en nu hier.
Ik ben echt de pineut.

[William_H]

Jup, beide waren best bekende bedrijven om kabels bij te bestellen. Maar blijkbaar zat er simpele IT achter, want ze zijn beide gehackt. Beetje balen inderdaad.

[TwitchyNL]

Simpele IT? Ze zouden beter moeten weten. Deze sites zijn allemaal van de eigenaar van de ICT dienstverlener Spete.nl uit Nijmegen, ze zitten ook in hetzelfde pand. Vergelijk de fotos op deze sites een met het smoelenboek op spete.nl, dit zijn gewoon systeembeheerders en SD medewerkers.

[Marchel]

Je bent niet de enige!

[Reactie gewijzigd door Marchel op 22 juli 2024 23:10]

[AibohphobiA BoB]

Nee, dan was het ook geen probleem geweest.

[Jehannes Z]

half tweakers gok ik

[Xfade]

Ik wacht nog op een dikke, coolblue ofzo. Echt alles op straat, waar je simpel een persoon kan google'n. Kan geen overheid tegen op treden.

[Anoniem: 30722]

Wordt het niet eens tijd dat de overheid ingrijpt en de bewaartermijnen drastisch omlaag brengt?
Elke online aankoop moeten ze 7 jaar gegevens van bewaren, maar als je iets in een winkel koopt en contant afrekent is de administratie 0,0.
Met de hoeveelheid hacks en lekken, lijkt het me toch een heel fijn idee als bedrijven de data na een maand MOETEN verwijderen. (of opt-in als je dit als service in een account wilt houden)

[Anoniem: 696166]

succes met je garantie

[Anoniem: 30722]

Bonnetje bewaren 👍 (pdf/mailtje)
Net als we de afgelopen 100 jaar doen in fysieke winkels.

[Reactie gewijzigd door Anoniem: 30722 op 22 juli 2024 23:10]

[Kaoh]

bonnetje is natuurlijk al een heel stuk administratie aan de winkel kant. Kassa systemen worden volgens regels gebouwd zodat die op de juiste manier de administratie vast legt (ja ik weet dat daar genoeg mee gerommeld wordt, maar het was wat mogelijk was met de techniek die mogelijk was ).
Maar inderdaad, voor een winkel transactie hoef je niet elke keer te legitimeren, maar dat is niet omdat de belasting dat niet nodig vind, maar omdat het nu niet werkbaar is. Mocht dat ooit wel kunnnen....

[Anoniem: 30722]

Een kassa slaat een bon op met een bon nummer. Die staat er ook op. Zo kun je valse bonnen er uit halen. Grote punt is dat een webshop naast een bon nummer ook al je naw en betalings informatie moet bewaren. En het gaat gewoon te vaak mis, daarmee is de consument de dupe van de belastingregels. En dan komt de vraag: wat weegt zwaarder. Privacy of controle door de belastingdienst. Zouden best interessante kamervragen kunnen zijn denk ik.

[Kaoh]

Zeker, maar ik zet mijn geld op de belastingdienst. Tot nu toe wint het controle door de belastingdienst argument bijna alle privacy discussies.

[jurroen]

Ligt er een beetje aan. In principe hoef je geen NAW gegevens vast te leggen bij een verkoop aan een particulier, mits het leveradres binnen Nederland is.

[Generaal Pep]

Vertel dat maar aan ome belastingdienst... dat gaat er niet in kan ik je nu al vertellen..

In een winkel kopen, contant afrekenen en 0,0 administratie? Ik mag hopen dat je aan die mensen wel korting hebt gevraagd, alvorens je hebt besloten om ze zwart te betalen

Edit: Bij nader inzien mijn pro-tip weggehaald, waar ik dat persoonlijk liever niet op internet plaats - voordat het tractie krijgt.

[Reactie gewijzigd door Generaal Pep op 22 juli 2024 23:10]

[Anoniem: 30722]

Contant is niet altijd zwart hè. (Wat de winkelier doet is zijn uitdaging, maar dat zijn niet mijn gegevens)

[Generaal Pep]

Je begrijpt mijn reactie niet, maar dat is niet erg

[RRRobert]

DSIT zegt het datalek te hebben gemeld bij de Autoriteit Persoonsgegevens, zoals verplicht is in dergelijke gevallen.

Hoeveel tijd zit er eigenlijk tussen de hack en het melden van de hack bij AP? Of beter gezegd, hoeveel tijd mag daar tussen zitten? De hack is intussen al weer zes weken oud en ik lees op GoT dart er klaarblijkelijk vandaag waarschuwingsmails zijn verstuurd naar de klanten, terwijl er vijf weken geleden al meldingen kwamen van phishing mails die uit naam van deze webshops waren verstuurd.

[melgior]

"Indien een inbreuk in verband met persoonsgegevens heeft plaatsgevonden, meldt de verwerkingsverantwoordelijke deze zonder onredelijke vertraging en, indien mogelijk, uiterlijk 72 uur nadat hij er kennis van heeft genomen, aan de overeenkomstig artikel 55 bevoegde toezichthoudende autoriteit, tenzij het niet waarschijnlijk is dat de inbreuk in verband met persoonsgegevens een risico inhoudt voor de rechten en vrijheden van natuurlijke personen. Indien de melding aan de toezichthoudende autoriteit niet binnen 72 uur plaatsvindt, gaat zij vergezeld van een motivering voorde vertraging."

Artikel 33 - Lid 1 AVG

Maar dat is dus alleen voor de melding aan AP, ik weet eigenlijk niet ook of er eisen zijn aan hoe snel je het de getroffen klanten moet melden

[Reactie gewijzigd door melgior op 22 juli 2024 23:10]

[One-eye864]

Het gaat niet zo zeer om de tijd tussen het datalek (de hack) en het melden maar om de tijd tussen het constateren van het datalek en het melden van het lek bij de AP. Dit moet binnen 72 uur gebeuren.

Bron: zie "Vragen over de melding bij de AP"