Webwinkel ReplaceDirect en zustersite Twindis melden datalek - update

ReplaceDirect en Twindis hebben te maken met een datalek als gevolg van een 'menselijke fout'. Meerdere Tweakers melden dat ze phishingmails ontvangen op basis van de gelekte gegevens. Betaalgegevens zijn volgens moederbedrijf MyMicro Group niet uitgelekt en het lek is nu dicht.

Volgens communicatie van ReplaceDirect en Twindis naar hun klanten gaat het om namen, adressen, e-mailadressen, versleutelde wachtwoorden en de bestelhistorie van klanten. De twee webwinkels zijn onderdeel van dezelfde infrastructuur. Transacties worden door een ander bedrijf afgehandeld en de financiële gegevens zijn dus buiten schot gebleven. Moederbedrijf MyMicro Group zegt bij klanten een wachtwoord-reset door te hebben gevoerd omdat het niet kan garanderen dat de versleutelde wachtwoorden niet ontsleuteld worden door een kwaadwillende. Dit geldt mogelijk alleen voor gebruikers wier gegevens ook daadwerkelijk gelekt zijn. Wat voor encryptie de twee webwinkels precies hanteren, wil algemeen directeur Mark Lebouille niet kwijt aan Tweakers.

Naar aanleiding van het lek zegt het bedrijf een extra diepgaande veiligheidstest uit te laten voeren op zijn systemen. Op maandag 25 april maakte een klant melding van een phishingmail op basis van gegevens die bekend zijn bij de webwinkels. Op dinsdag 26 april werd het lek ontdekt en direct gedicht. Het gat, dat ontstaan is door een verkeerde firewall-instelling, is mogelijk nog langer dan dat aanwezig geweest.

Op het Tweakers-forum maken gebruikers melding van de phishingmails. Deze mails zijn aangekleed om sterk te lijken op communicatie van PayPal. Kwaadwillenden proberen op deze manier de inloggegevens van gebruikers te achterhalen. Gebruikers met een account bij ReplaceDirect of Twindis doen er goed aan om hun wachtwoorden te veranderen als deze op andere sites hetzelfde zijn als bij de webwinkels in kwestie. Bovendien is het zaak om kritisch te blijven wat betreft e-mails van bijvoorbeeld PayPal. De phishingmails zijn op het eerste gezicht namelijk zeer overtuigend.

Update, 13:46: het blijkt dat niet alleen ReplaceDirect maar ook zustersite Twindis te maken heeft met hetzelfde datalek. Het artikel is hierop aangepast.

Reacties (112)

[CAPSLOCK2000]

Het gat, dat ontstaan is door een verkeerde firewall-instelling, is mogelijk nog langer dan dat aanwezig geweest.

Ik vind het eerlijk gezegd niet zo'n best verhaal. Als je veiligheid afhangt van een firewall ben je verkeerd bezig*. Een firewall is een secundaire maatregel om te compenseren voor gebreken in andere beveiliginsmaatregelen. Een goede vuistregel is om bij het beveiligen van je systeem te doen alsof er geen firewall is, dan moet het nog steeds veilig zijn.

Een gat in een firewall is zo iets als een defecte airbag. Een defecte airbag is niet de oorzaak van ongeluk. Een airbag kan de gevolgen van een ongeluk verkleinen, maar de oorzaak van het ongeluk ligt elders. Geen enkele chauffeur zegt na een ongeluk "als mijn airbag het had gedaan dan was er niks aan de hand geweest".

* Ik weet ook wel dat de praktijk vaak moeilijk is. Onder druk van tijd en geld heb ik ook wel eens keuzes gemaakt waar ik niet gelukkig mee ben. Dat is een reden, geen excuus.
Het nadeel van het grote aantal concurrerende webshops van tegenwoordig is dat de marges laag zijn waardoor er een enorme druk bestaat om alles zo goedkoop mogelijk te doen.

[Anoniem: 423815]

[...]
Ik vind het eerlijk gezegd niet zo'n best verhaal. Als je veiligheid afhangt van een firewall ben je verkeerd bezig*. Een firewall is een secundaire maatregel om te compenseren voor gebreken in andere beveiliginsmaatregelen. Een goede vuistregel is om bij het beveiligen van je systeem te doen alsof er geen firewall is, dan moet het nog steeds veilig zijn.

Dit is niet helemaal waar. Een DDoS beveiliging of eender welke andere firewall beveiliging heeft als functie om aanvallen af te leiden, VOOR het je server-side script bereikt. Je kan je code nog zo goed mogelijk beveiligen tegen aanvallers, maar vanaf dat je verkeer vanaf meerdere IP adressen tegelijk krijgt ga je die niet kunnen "onderscheiden". Je zal dus ofwel te aggresief reageren en bijvoorbeeld een boodschap tonen dat de dienst tijdelijk onder aanval ligt, waardoor ook gewone mensen deze krijgen ofwel te passief reageren op die pakketten en bij een overvloed kan je server niet meer reageren op de aanvragen bij gebrek aan resources / threads waardoor mensen 503 of 404 krijgen.

Leg mij eens uit hoe jij in jouw code zulke (in principe firewall-gerelateerde) zaken gaat voorzien zonder een terugkoppeling naar, jawel, je firewall via een applicatie zoals Fail2ban bijvoorbeeld?

[...]
Het nadeel van het grote aantal concurrerende webshops van tegenwoordig is dat de marges laag zijn waardoor er een enorme druk bestaat om alles zo goedkoop mogelijk te doen.

Dat is dan weer helemaal wél waar, spijtig genoeg.

[CAPSLOCK2000]

Dit is niet helemaal waar. Een DDoS beveiliging of eender welke andere firewall beveiliging heeft als functie om aanvallen af te leiden,

Ok, dat klopt, maar dat is een ander soort beveiling dan waar ik het over had. Misschien is het woord "beveiliging" onhandig gekozen omdat het verschillende gebieden bestrijkt.
Jij hebt het over de beschikbaarheid van de dienstverlening, ik heb het over ongeautoriseerde toegang tot data. Een DDOS kan er voor zorgen dat niemand meer toegang heeft tot de data maar er zal geen data in de verkeerde handen komen.

Ik wil niet zeggen dat firewalls geen toegevoegd waarde hebben, mijn punt is dat je er niet afhankelijk van wil zijn. In het algemeen wil je beveiliging altijd in lagen opbouwen zodat gaten in de ene laag worden afgedekt door de andere lagen. Een firewall is een goede laag maar zou nooit de enige laag mogen zijn.
Hoe groter de behoefte aan beveiliging, hoe meer lagen je nodig hebt. Persoonsgegevens alleen beveiligen met een firewall vind ik nalatig.

[cefas]

Dit is niet de eerste keer dat replacedirect zulke problemen heeft, wat ik wel erg bijzonder vind dat het net als in mijn geval om precies dezelfde soort erg persoonlijke paypal spam gaat..... toeval ik denk het niet.

Zie ook mijn topic van 10 januari 2015 Wel erg persoonlijke spam in de spam box

[Madmama]

Ik heb ineens een vermoeden om welke spam het gaat. in mijn geval gaat het om mails afkomstig van ICS/Visa omdat ik daar ook mee betaald heb. Heb jij toevallig met paypal bij replacedirect betaald?

Ik heb de afgelopen dagen 3x mail gehad zogenaamd vanuit ICS (Visa) met daarin mijn achternaam keurig voluit gespeld zoals ik deze achter zou laten bij officiële sites (normaal gebruik ik een verkorte versie), ik heb deze mail gehad 2x op mijn prive adres en 1x zakelijk.

Het viel me op dat deze mails linken naar sites gehost bij transip, na het op de hoogte stellen van transip zijn de sites ook netjes offline gehaald.

Ik heb zowel prive als zakelijk dingen besteld bij replacedirect, dus zodoende zijn beide mail adresseren daar bekend (heb in beide gevallen ook mijn visa gebruikt om producten af te rekenen)

edit: ik zie dat beide domeinnamen waar spam op gehost werd vrij zijn gegeven, mocht je willen zoeken in je mail body: imagserv.nl en uselesss.nl waren 2 van de namen waar naar toe werd gelinkt.

[Reactie gewijzigd door Madmama op 22 juli 2024 15:53]

[bogy]

ik heb zowel bij replacedirect als bij twindis (zakelijk) een account...
dit is niet leuk .. het wachtwoord dat ik daar gebruikt heb en het bijhorende email adres heb ik maar op een paar plaatsen gebruikt; in ieder geval geen belangrijke zaken voor zover ik weet...

[xalvo]

Niet alleen ReplaceDirect heeft hier mee te maken. Enorm veel bedrijven en instanties lekken gegevens als een vergiet. Enerzijds omdat ze hun systemen niet op orde hebben of omdat hun personeel de gegevens gewoon mee kan nemen.
Om je een indicatie te geven, mijn spambox hangt vol met emails van met gegevens vam oa Het Kadaster, Schiphol (parking), Monsterboard, Pixmania, Salland automatisering, AT Bank, Plattetv, en ga zo maar door.
Stuk voor stuk unieke gegevens ingevuld, die vervolgens gewoon in spam terug komt.
De meeste organisaties doen vervolgens ook nog 0 met een melding.
Ik hoop dan ook dat de huidige meldingsplicht daar wat verandering in brengt. Getuige dit nieuwsbericht heeft het wellicht iets effect, al heb ik er in het algemeen mijn twijfels over.
Bijzonder spijtig ook dat ze niet willen aangeven hoe sterk hun encryptie is, na een lek vind ik dat je als gedupeerde in ieder geval mag weten of je gegevens goed beveiligd waren.

[Whatts]

ik heb een account op de .be en op de .nl en ik heb enkel op .nl mijn wachtwoord moeten veranderen. Heeft er iemand het op .be moeten aanpassen?

Edit: er blijkt wel wat meer aan de hand te zijn momenteel, na inloggen zit ik plots in iemand anders zijn account, met adresgegevens en al de rest toegankelijk.

[Reactie gewijzigd door Whatts op 22 juli 2024 15:53]

[foienoord]

Dat had ik net ook, daarna uitgelogd en weer proberen in te loggen toen kreeg ik een fout melding

[Whatts]

Idem hier. Ik heb 2x een andere account gekregen, heb ze daarna direct opgebeld.

[svenslootweg]

Wat voor encryptie ReplaceDirect en Twindis precies hanteren, wil algemeen directeur Mark Lebouille niet kwijt aan Tweakers.

Dat zegt me genoeg, denk ik. Daar bestel ik dus nooit wat.

EDIT: Ter verduidelijking: het feit dat ze deze informatie niet vrijgeven toont aan dat ze ofwel weten dat het niet afdoende is en dit proberen te verzwijgen, ofwel niet begrijpen dat dit geen gevoelige informatie is of moet zijn, en dus 'security through obscurity' hanteren. In beiden gevallen zijn ze dus niet te vertrouwen op het gebied van beveiliging.

[Reactie gewijzigd door svenslootweg op 22 juli 2024 15:53]

[Tozz]

Of de beste man weet het niet omdat hij directeur is en niet alle details van de programmatuur weet. Of hij vindt (terecht) dat dat niet relevant is voor hetgeen er nu speelt.

Als de beste man antwoord had gegeven was het namelijk nooit goed. Want als hij zegt het was methode X dan roept iedereen ja maar je moet ook methode Y doen. En als ie dat had gezegd riep iedereen je moet ook een salt, terwijl dat misschien wel werd gedaan. En als ie erbij zegt dat het gesalt wordt dan roept iemand dat het bij elke login opnieuw gesalt moet worden. En misschien gebeurt dat ook wel, maar vertelt ie al die minieme details niet.

Kortom, door dit soort informatie prijs te geven krijg je toch alleen maar meer gezeur, want het Internet zit vol met cryptoexperts die het allemaal beter weten. Dus geheel logisch dat ie dat niet verklapt, omdat het ook niet zo relevant is. De mogelijkheid dat het wachtwoord misschien te decrypten is binnen X tijd staat m.i. niet in verhouding tot het lekken van allerlei persoonsgegevens.

[Reactie gewijzigd door Tozz op 22 juli 2024 15:53]

[dnrb]

Wees nou blij dat dit bedrijf het fatsoen heeft om het te melden, vele dsoen het niet en bij sommige is het zelfs onmogelijk om te melden dat er bij hen een lek is. GSM Web heeft er ook 1 gehad maar dat melden gaat niet. Ik kan dat zien omdat ik een eigen domein heb en altijd de naam van het berijf at gebruik dus:
gsmweb@......nl, ing@.............nl of kpn@.......nl om met bedrijven te communiceren.
Als ik opeens spam of phisingmail krijg dat naar zo'n email adres gestuurd word weet ik dus waar het lek zit.
Helaas kan ik bij deze reactie geen plaatje plakken maar een jassen bedrijf uit tjechije stuurde mij een mail met als afzender: wol=[e-mail] naar gsmweb@......nl
GSMWEB heeft nooit gemeld dat zij gehackt zijn...

[dimitrivs]

Daar hoef je niet noodzakelijk een eigen domein voor te hebben, dit principe gaat gmail ook.

Stel je hebt volgend adres [e-mail], dan kan je op 2 manieren adressen maken die toch in dezelfde box terecht komen.

1. puntjes toevoegen
[e-mail]
[e-mail]
[e-mail]
2. '+' teken en achtervoegsel toevoegen:
[e-mail]
[e-mail]

Afgezien dat je bv kan weten waar dit adres is buitgemaakt, geeft dit ook wat extra filtermogelijkheden.

Net zoals Borromini heb ik ook al bij ReplaceDirect.be besteld, maar ook nog geen mail ontvangen.

[Anoniem: 221563]

Hmmz, dat + teken verhaal kende ik nog niet, de puntjes wel. Ideaal tijdens de ontwikkeling van een inlogsysteem dat controleert op unieke mailadressen

[Terriongaming]

Het fatsoen? Ze zijn bij de wet verplicht dit te melden bij het meldpunt datalekken en degene die getroffen zijn door het datalek, sinds 1 januari 2016.

[dnrb]

Helaas doet niet elk bedrijf dat, zie mijn voorbeeld over GSMWEB. Punt is, is er ooit een bedrijf beboet die deze wet overtrad? En stond de boete in verhouding met de laksheid van dit bedrijf?

[Terriongaming]

Dan heeft het nog steeds weinig te maken met fatsoen, maar met het volgen van de wet. Dat bedrijven dit aan de laars lappen is een ander verhaal.

[Sunthon]

Een duidelijk mail van ReplaceDirect die ook ik heb ontvangen, maar geen excuses... blijkbaar vond de directeur dat niet nodig. 't Zal aan mij liggen...

[Wodanford]

Het verbaast me altijd hoeveel belang mensen hechten aan excuses. Je hebt er helemaal niks aan en je wordt er niks wijzer van. Beter kan de "excuserende partij" gewoon duidelijk zijn in wat er mis ging, waarom het mis ging en wat men gaat doen om herhaling te voorkomen. Ik ken de inhoud van de mail niet, maar als ik het artikel hier op Tweakers lees dan heeft RD genoeg informatie verschaft.

Edit: cefas meldt dat RD vaker deze problemen heeft. Een mooi voorbeeld van wat je dan aan excuses hebt.

[Reactie gewijzigd door Wodanford op 22 juli 2024 15:53]

[Sunthon]

Ik vind het een kwestie van fatsoen. Niet meer en niet minder. Nu komt het allemaal onverschillig over "foutje, wij hebben het hersteld, doei!".

[Zer0]

Wat heb je liever, een hoop tijd steken in het formuleren van een de email, of asap de gebruikers op de hoogte stellen?

[DrClaw]

ze zijn nu wettelijk verplicht om de autoriteit persoonsgegevens binnen 72 uur op de hoogte te stellen, dus dat moet sowieso. En als sommige gegevens onversleuteld zijn, en een inbreuk op de persoonlijk levenssfeer kunnen verrichten, dan moeten ze ook gebruikers inlichten.

https://autoriteitpersoon...den/meldplicht-datalekken

In zo'n bericht moeten ze aangeven wat er is gebeurd, en welke gegevens er vrijgekomen zijn. Nergens staat iets van excuses, en imho is dat ook niet belangrijk. Als ze maar wat aan de oorzaak van het lek gaan doen (en als ze dat zouden toelichten, dan ben ik een heel stuk blijer dan met een set excuses).

[Crystical]

Ja. Even excuses opschrijven kan misschien wel 20 seconden kosten. Dat kan echt niet hoor.

Excuses aanbieden is gewoon een beetje fatsoen. Als bedrijf mag je wel een beetje je best doen om good will op te bouwen na een datalek..Excuses aanbieden is dan wel het minste.

[Reactie gewijzigd door Crystical op 22 juli 2024 15:53]

[Neko Koneko]

Ja. Even excuses opschrijven kan misschien wel 20 seconden kosten. Dat kan echt niet hoor.

Excuses aanbieden is gewoon een beetje fatsoen. Als bedrijf mag je wel een beetje je best doen om good will op te bouwen na een datalek..Excuses aanbieden is dan wel het minste.

Als excuses niet gemeend zijn hoef ik ze ook niet te hebben.

[Crystical]

Ik ook niet. Maar ik ga ervan uit dat als ze in eerste instantie dat wel hadden gedaan, ze gemeend zouden zijn. Ben niet graag cynisch..geef liever het voordeel van de twijfel.

[Donstil]

Precies, fatsoen daar gaat het om idd.

Als ik als consument (of als bedrijf als het aankomt op twindis) mijn zuur verdiende centen bij een bedrijf breng dan is dat wel het minste wat ik terug verwacht als ze mijn gegevens lekken.

Een excuses mailtje kost een paar minuten, daar kan de marketing afdeling nooit lang mee bezig zijn.

Een stukje korting op je volgende bestelling had ook wel gemogen trouwens, zeker als je ziet wat twindis voor prijzen vraagt voor vaak niet meer dan goedkope Chinese producten.

[Reactie gewijzigd door Donstil op 22 juli 2024 15:53]

[Anoniem: 636203]

Helemaal gelijk. Gewoon fatsoen, ook al heb je er wenig aan. En een geldelijke compensatie zou ik ook wel erg op prijs stellen voor dit soort knulligheden.

Gelukkig koop ik nooit iets bij ReplaceDirect. En na vandaag ben ik niet van plan om dat ooit nog te doen.

[mae-t.net]

Excuses, of op andere manier een schuldbewuste toon en full disclosure. Dat laatste geven ze in elk geval niet; zo wordt er bijvoorbeeld niet vermeld hoe de wachtwoorden versleuteld zijn. Indien niet vermeld neemt de lezer ROT13 aan of iets dergelijks en dat is een grotere klap in het gezicht van de klanten dan het ontbreken van schuldbewustheid of nederigheid.

Voor de duidelijkheid: het kan véél erger, maar om te zeggen dat ze het prima afhandelen, lijkt mij overdreven.

[Reactie gewijzigd door mae-t.net op 22 juli 2024 15:53]

[enomiss]

Ze beginnen de e-mail ook met "Graag brengen wij je via deze e-mail op de hoogte van een lek in één van onze systemen."

Beetje de verkeerde toon als je het mij vraagt... "Graag" had beter "tot onze spijt" of iets dergelijks mogen zijn.

[Reactie gewijzigd door enomiss op 22 juli 2024 15:53]

[Aikon]

Bij de link in het artikel staat wel 'tot onze grote spijt'. Snel aangepast of stond dat er al?

[dclrcq]

Ik kreeg daarnet ook de mail en daarin staat

"Tot onze spijt brengen wij u via deze e-mail op de hoogte van een lek in één van onze systemen. "

Blijkbaar lezen ze mee op tweakers.

[Kiswum]

Blijkbaar hebben ze het op de site wel correct staan, zie link in dit artikel:

Tot onze grote spijt moeten we je melden dat we een lek hebben geconstateerd in één van onze systemen

[BtM909]

Op http://www.replacedirect.nl/datalek staat wel de spijtbetuiging, btw

[DJMaze]

Daar mogen ze "De ingang is ontstaan door een menselijke fout" ook wel verwijderen.
Of hebben ze ook aliens, apen en kabouters in dienst?

[i-chat]

een menselijke fout wijst hier naar een fout van de beheerder, en dus niet in onvoorziene complicatie in bijv programmeer code...

om je een indicatie te geven, windows wordt als relatief veilig genoeg (voor productie) beschouwd, toch zit het vol bugs en moeten er maandelijks tientallen patches worden uitgerold, echter is die software zo complex dat je moeilijk kunt spreken van menselijke fouten, maar zodra iemand een update uitrolt die helemaal niet bedoelt was voor het grote publiek spreek je wel weer van een 'strikt menselijke' fout.

[iceheart]

Tja, beetje lullige manier om admin-fout te benoemen, maar je snapt zelf ook wel dat ze bedoelen dat de fout door hun admin is gemaakt en niet dat het een bug in de gebruikte software was

[mae-t.net]

Een menselijke fout als oorzaak noemen, is toch een stuk duidelijker dan geen oorzaak noemen! Ik schreef eerder al dat het heus geen schoolvoorbeeld is, maar het kan vééél slechter.

[gjmi]

Inderdaad, een excuus is wel op zijn plaats. Maar niets daarvan in de mail.

[harrytasker]

Ach ja, ze hadden ook gewoon niets kunnen melden of veel te laat, dat gebeurt ook nog veel te vaak...

[Rub147]

Wel fijn dat ReplaceDirect haar klanten op de hoogte stelt. Ik heb m'n mail nog eens bekeken, maar ik kan geen mail vinden van ReplaceDirect over dit lek...

[Xtuv]

Wellicht zijn je gegevens dus niet buitgemaakt. Bij de uitleg van ReplaceDirect staat:

Ik heb eerder een bestelling geplaatst, zijn mijn persoonlijke gegevens nog veilig?
Heb je een bestelling bij ons geplaatst voor 26 april 2016? Dan bestaat er een kans dat er persoonlijke gegevens inzichtelijk zijn geweest voor kwaadwillende personen. In die situatie heb je van ons een bericht gekregen dat wij je account wachtwoord hebben geblokkeerd.

Daaruit is op te maken dat getroffen klanten een bericht hebben gekregen.

[BikkelZ]

Inderdaad een mailtje gehad.

[HenkDePoema]

In de mail van ReplaceDirect staat:

• Alle wachtwoorden van onze klanten zijn geblokkeerd.

Dat betekent dus dat in elk geval de klanten die voor 26 april een bestelling hebben geplaatst dit bericht hebben gekregen of nog krijgen.
Of die klanten automatisch ook getroffen zijn, valt hieruit niet te concluderen.

[Murfy]

Geen idee waarom dit gedownmod werd, maar ik heb het ook moeten vernemen via Tweakers..

[DukeMan]

Ik heb de mail pas zojuist ontvangen, dus wellicht komt deze nog?

[biomass]

Ik heb een uur geleden een/het mailtje gekregen van replacedirect. Aangezien een telefoonnummer ook verplicht is in een gebruikersprofiel bij replacedirect, lijkt het me erg sterk dat die gegevens niet ook gestolen zijn. Jammer dat ze dat niet ook bevestigen of ontkennen.

Date: Wed, 27 Apr 2016 12:37:02 +0200 (CEST)

Ik heb nog geen phishing mail ontvangen, maar dat kan liggen aan het aantal mail adressen dat gestolen is, of er is gefilterd. Ik heb in mijn profiel een adres gebruikt dat de teruglinkt naar de shop. Wellicht dat ze dergelijke adressen niet gebruiken om zo lang mogelijk onopgemerkt te blijven..

[fbax]

Ik heb reeds om 11:10 een mail ontvangen, waarschijnlijk heb jij geluk en zijn jouw gegevens niet gelekt?

[memphis]

Wel gehad maar vertrouwde het niet gezien ik gister een soortgelijke mail van omroep MAX had gekregen en ik niets met hun heb.

[gabba25]

Maar is mijn wachtwoord nu bekend? Dat is me niet helemaal duidelijk.

/edit:

Het bedrijf zegt bij iedere klant een wachtwoord-reset door te hebben gevoerd omdat het niet kan garanderen dat de versleutelde wachtwoorden ontsleuteld worden door een kwaadwillende

Niet goed gelezen. Toont maar waar aan dat je nooit dezelfde wachtwoorden moet gebruiken.

[Reactie gewijzigd door gabba25 op 22 juli 2024 15:53]

[Whatts]

De wachtwoorden zijn gelekt maar versleuteld en dus niet plain text. Natuurlijk weet je niet hoe ze versleuteld waren (welk hashing algoritme, salted of niet, vaste salt of variabel enz).

[mae-t.net]

Aangezien ze weigeren te melden wat voor versleuteling ze gebruikten, zal het niet de veiligste zijn geweest. Ik vind het verstandig om dan uit te gaan van iets als ROT13. Zelf gaan ze daar gelukkig ook van uit en hebben keurig een reset uitgevoerd.

[Reactie gewijzigd door mae-t.net op 22 juli 2024 15:53]

[harrytasker]

"Ondanks dat wij wachtwoorden versleuteld opslaan, kunnen we niet garanderen dat ze eenmaal in handen van derden niet ontcijferd worden. Daarom hebben we uit voorzorg het wachtwoord van jouw ReplaceDirect account geblokkeerd."
Staat er toch duidelijk in de email?

[Reactie gewijzigd door harrytasker op 22 juli 2024 15:53]

[Anoniem: 636203]

Ik gebruik Password Safe die zelf zware wachtwoorden genereert. Kan ik iedereen aanraden.

[Hackus]

Dit is waarom ik groot voorstander ben van "Kopen als gast".
waarom zou ik overal een account aanmaken en al mijn gegevens daar achter laten.

[Emile74]

Bij Replacedirect maken ze dan als 'service' alsnog een account voor je met al je gegevens er in zonder dat je daarom hebt gevraagd.

[Tim.k]

Helaas is kopen als gast bijna overal een illusie.

Voor de administratie zullen ze toch 90% van de gegevens bij moeten houden die je ook moet invullen als je je registreren waardoor bijna alle webshops de data wegschrijven in de zelfde tabellen in de database enkel met de optie om in te loggen uitgeschakeld.

[Murfy]

Aan hun password-reset link te zien gebruiken ze BCrypt, ik hoop dat ze dat ook voor hun wachtwoorden hebben gebruikt dan.

edit: wil ik een nieuw wachtwoord instellen, en de enige speciale tekens die zijn toegelaten, zijn _ en -..? Uit welk tijdperk komen zij?

Een geldig wachtwoord bestaat uit de letters a t/m z, A t/m Z, cijfers en de tekens - en _. Verder is het belangrijk dat uw wachtwoord tussen de 8 en de 20 tekens bevat.

[Reactie gewijzigd door Murfy op 22 juli 2024 15:53]

[Menesis]

Zelfde bij Binck bank... echt triest dat soort dingen.

[rvtk]

Daar heb je gelukkig wel two factor authentication.

[mae-t.net]

Om het over de limiet van 20 tekens nog maar niet te hebben. Dat is misschien nog wel een beetje 2010 dus niet sterk verouderd, maar het is niet 2020.

[Armin]

20 tekens is 160bit, dus als men SHA1 als onderliggend hash/encryptie-algorithme heeft (uiteraard/hopelijk verpakt in een hoger algorithme) is dat zo gek nog niet.

Langer dan 20 tekens is immers qua veiligheid niet nodig indien je wachtwoord sterk is qua vorm, en langer dan het onderliggende hash-algorithme is onzinnig want de extra entropie gaat toch verloren.

[mcmd]

Gezien de toegestane karakters, max 64 karakters (6 bits), is de maximale sterkte van het wachtwoord 120 bits. Ruim voldoende indien het wachtwoord goed gekozen is!

[Gomez12]

Een langer wachtwoord hoeft dan ook niet altijd om de extra entropie te gaan, het kan ook gewoon gaan om het feit dat je wilt dat het niet de 1e collission is.

[Armin]

Of het de 1e of 100e collission is maakt natuurlijk niet uit. Immers als er een string gevonden is, die de gewenst hash produceert, is de aanvaller binnen.

De lengte van het wachtwoord is in eerste instantie enkel om brute force en aanverwante aanvallen tegen te gaan. Zodra je echter een bepaalde lengte hebt, is meer tekens irrelevant. Immers of het 100 miljoen jaar duurt, of 2 biljoen jaar duurt om iets te kraken maakt immers uit. Dus of je dan de 1e of 2e collission bent maakt niet uit, want mathematisch zit je gewoon veilig. Meer sloten op een reeds goed beveiligde deur is onzinnig.

Een tweede nevenvoordeel van een langer wachtwoord is dan enkel dat je meer entropie hebt in de resulterende hash. Echter zodra je boven de sterkte van het algorithme uitkomt gaat die eventuele extra entropie verloren.

Het gevaar is dan verder dat omdat langere wachtwoorden moeilijk zijn, je vanwege de extra lengte weer (onbewust) patronen gaat gebruiken. Je wachtwoord is dan juist zwakker in zogenaamde token-patroon aanvallen. En laat die juist tegenwoordig de meeste gebruikte en ook meest gevaarlijke aanvallen zijn.

Dat brengt me op het volgende punt: dat je helemaal niet weet hoe de aanvaller te werk gaat. Zo goed als 100% zeker dat die helemaal niet serieel te werk gaat met a,b,c,...z,aa,ab,..,etc en dus jouw langere wachtwoord wellicht helemaal niet een lagere collission is, maar juist een van de eerste ivm een patroon. Je weet het niet.

Beter is je te richten op een minimale lengte van laten we zeggen 12 a 16 tekens ivm brute force, en alle andere aandacht besteden aan zo veel mogelijk "randomness".

Gebruik je een computer gegenereerd wachtwoord, gebruik dan de maximale lengte en je weet dat het goed zit ook al is het beperkt tot 'maar' 20 tekens (of effectief zelfs maar 15 - 120 bits). En gebruik je een niet-computer gegenereerd wachtwoord, is het beter de pijlen daar op te richten ipv het langer te willen maken want dat zet meer zoden aan de dijk.

[mae-t.net]

Een wachtwoord langer dan 20 tekens of zo je wilt een passphrase, is bijvoorbeeld veiliger als je het beter kunt onthouden dan een misschien encryptietheoretisch sterker wachtwoord dat korter is maar op een postit genoteerd moet worden.

[Reactie gewijzigd door mae-t.net op 22 juli 2024 15:53]

[Armin]

Uiteraard, maar dat is een geheel ander punt. Overigens de postit is niet noodzakelijk slecht. Als de aanvaller in China zit bijvoorbeeld. Persoonlijk adviseer ik echter mensen wel degelijk depostiot tehcniek. Dwz tijdelijk, totdat je het uit je hoofd kent. Daarna kan de postit in een papieren boekje thuis in de kast.

Maar je geeft wel mooi mijn punt aan: "Een wachtwoord langer dan 20 tekens of zo je wilt een passphrase, is bijvoorbeeld veiliger als je het beter kunt onthouden"

En daarom adviseer ik altijd geen onnodig lange wachtwoorden te gebruiken. Mensen gaan namelijk bijna altijd patronen gebriuken, zoals een passphrase. Passphrases zijn vaak een appletje eitje voor hackers. Zelfs veel Tweakers zijn niet goed op de hoogte hoe hacker te werk gaan in het aanvallen van passworden. Die denken dat de gangbare techniek nog steeds dictionary, brute force of rainbow tables is. In realiteit zijn het patroon-aanvallen, en elke patroon is dan dodelijk voor de sterkte in je wachtwoord. Hoe makkelijker voor de mens, hoe makkelijker voor de computer.

Dus 12 a 16 tekens echt of bijna random is doorgaans veel beter dan een laten we zeggen 32 tekens lange passphrase, zelfs als het hash algorithme het niet effectief zou afkappen op 20 tekens.

[mae-t.net]

Dat is inderdaad een stukje dat ik niet zo goed onder de knie heb. Hoe moet ik me een patroonaanval voorstellen op een zin die uit al dan niet bestaande woorden en misschien ook nog wel leestekens en cijfers bestaat? De mogelijkheden lopen dan zo hard op dat zelfs een patroon ontdekken lastiger kan zijn dan in korte wachtwoorden, althans dat veronderstel ik?

[Reactie gewijzigd door mae-t.net op 22 juli 2024 15:53]

[Armin]

Er zijn twee problemen. Als je je lange zin/phassfrase moeilijk gaat maken (in feite meer echt random) wordt het inderdaad sterker, maar dat is niet het idee van een lange zin. Waarom niet 16 tekens 100% random? Omdat dat lastig is, en dus kiest men een 32 tekens zin, die men dan probeert weer moeilijk te maken. Maar niet te moeilijk, want dan kan de persoon hem niet onthouden. Dus je komt met een hybride iets wat patronen heeft (zodat je het kunt onthouden) en random.

Tweede probleem is dat wat jij kan bedenken andere mensen ook bedenken. Jij denkt dat je iets unieks doet met leestekens en hoofdletters, maar het blijkt dat andere mensen heel toevallig exact soortgelijke aanpassingen maken. Menslijke hersenen zijn nu eenmaal getraind in patronen en dus maken we zelfs schijnbaar willekeurige anapassingen met patronen.

Hackers hebben databases met miljarden entries waar ze met statistische analyse deze patronen analyseren. Dus zelfs die ene schijnbaar ogenschijnlijk wilelkeurige reeks tekens blijkt vaak voor te komen en wordt dus eerder geprobeerd dan andere tokens. De computer probeert met behulp van krachtieg GPU's eerst de veelvoorkomende tokens, en plaatst deze ook nog eens in allerlei semi-willekruige volgordens.

En tenslotet wat jij in het Nederlands als willekruige ziet, blijkt wellicht in het Lets of Kroatisch een grappige hippe afkorting te zijn.

Langere zinnen zijn een doodlopende weg. Ze bieden geen meerwaarde voor brute force tov een 12 a 16 tekens random wachtwoord en het is Russisch roulette of ze beter zijn tegen patroon-herkenning. En ergste is dat ze onbedoeld verkeerde gewoonten (namelijk patronen gebruiken) stimuleren bij minder technische gebruikers. Niet aan beginnen of meteen mee stoppen. Gebruik voor belangrijke zaken echt random gegenereerde zaken.

En voor niet belanghrijke zaken, maakt het doorgaans geen bal uit. Zorg ervoor dat die wegwerp wachtwoorden uniek zijn en je zit goed.