Online discussieplatform Disqus had in 2012 datalek

Op het internet is een snapshot van de database van discussieplatform Disqus opgedoken. Hackers hebben de gegevens in 2012 buitgemaakt. Bij een derde van de ongeveer 18 miljoen betrokken accounts is het wachtwoord, gehasht met sha-1, inbegrepen.

Disqus maakte het datalek op vrijdagmiddag bekend. De database bevat ook e-mailadressen, gebruikersnamen en, in plaintext, de data waarop de gebruikers ingeschreven en voor het laatst ingelogd zijn. De oudste data in de snapshot stamt uit 2007. De getroffen gebruikers hebben een automatische, verplichte wachtwoordreset gekregen van Disqus. Het platform stelt dat het geen ongeautoriseerde loginpogingen heeft waargenomen.

Disqus werd op de hoogte gesteld door Troy Hunt, beheerder van HaveIBeenPwned.com, die de gegevens in zijn dienst heeft verwerkt en leden via die weg ook op de hoogte heeft gesteld. Tegenover ZDnet stelt de security-expert overigens dat 71 procent van de bij Disqus uitgelekte e-mailadressen al te vinden waren in de database van Hunt. Disqus stelt tegenover de techsite dat het gaat om minder dan tien procent van het totale aantal accounts dat de dienst heeft.

Iedereen wiens account bij Disqus getroffen is, moet zijn wachtwoord daar veranderen. In het geval dat datzelfde wachtwoord elders gebruikt wordt, wat af te raden is, moeten gebruikers ook daar hun wachtwoord veranderen. Daarnaast is het ook sterk af te raden om een wachtwoord te hanteren dat vijf jaar oud is. Het sha-1-algoritme van de uitgelekte wachtwoorden is eerder dit jaar ook gekraakt en wordt nauwelijks nog gebruikt.

Reacties (52)

[OddesE]

Bij een derde van de ongeveer 18 miljoen betrokken accounts is het wachtwoord, gehasht met sha-1, inbegrepen.

Kijk hier mis is dus een stukje vitale info om het risico van deze hack in te kunnen schatten (ik heb een Disquss account, al heel lang). Namelijk:

Was het pasword gesalt?

Echt jammer dat deze info mist in dit artikel. Vooral omdat dit gewoon netjes in het bronartikel vermeld staat:

The snapshot includes email addresses, Disqus user names, sign-up dates, and last login dates in plain text for 17.5mm users. Additionally, passwords (hashed using SHA1 with a salt; not in plain text) for about one-third of users are included.

Voor de mensen die het niet weten; een salt is een stukje random info die wordt toegevoegd aan het wachtwoord voordat deze wordt gehashed. Dit is super belangrijk! Als men dit niet doet, dan betekent dat dat als 2 mensen hetzelfde wachtwoord hebben, ook de hashed versie hetzelfde is. En dus heb je als je één van die passwords gekraakt hebt ook automatisch het password van die andere account gekraakt.

Ook zorgt dit salten ervoor dat het lastiger wordt om rainbow tables te gebruiken. Dit zijn tabellen met (woordenboek) woorden en veelgebruikte passwords die al voor gehashed zijn. Komt een hash voor in de rainbow table dan is het vinden van het wachtwoord ineens super makkelijk. Daarom moet je ook proberen geen gewone woorden als wachtwoord te gebruiken. Tenminste niet slechts één gewoon woord. Een combinatie van drie of vier gewone woorden (passphrase) is dan wel weer veilig. Helaas zijn er nog veel te veel systemen die mensen dwingen slechte wachtwoorden te kiezen, door bijvoorbeeld lengte restricties er op te zetten of te dwingen bepaalde tekens te gebruiken. Onnodig. Vooral belangrijk is dat het wachtwoord lang is. Lastiger typen dat wel.

Wat deze hack betreft; door de salt zal de impact meevallen. Ze hebben hier gelukkig niet zo dom gedaan als Adobe destijds.

[KoenvZuijlen]

Jammer dat veel sites de peper nog vergeten:
https://blog.filippo.io/salt-and-pepper/

[Sinnergy]

In mijn systeem zijn de wachtwoorden gesalt met een salt per user, een salt (pepper?) hardcoded in de code en nog een die uit de config file komt

[eborn]

Het grote nadeel van een pepper is dat deze nooit meer te wijzigen is, zonder alle wachtwoorden te rehashen. Dat kan natuurlijk gedaan worden zodra iemand inlogt, maar dat betekent ook dat je moet gaan bijhouden welke 'versie' van de pepper is gebruikt per wachtwoord. Technisch prima mogelijk, maar het maakt het allemaal wel heel complex.

Als je toch met een hard-coded secret werkt, en het doel is om de omvang van de hack bij alleen een database leak te verkleinen, dan kun je je wachtwoorden beter encrypten via two-way encryption. Voordeel is dat je ze later kunt decrypten en daarmee de secret periodiek kunt wijzigen.

Let op: de two-way encryption is dus de 2e laag, bovenop de normale hashing via bijv. bcrypt met een hoge iteratie factor.

[Reactie gewijzigd door eborn op 24 juli 2024 19:09]

[iAR]

Ik kreeg inderdaad 2 dagen geleden een mailtje van Have I been pwned?, een dag eerder was Bitly ook al aan de beurt.

Voor een ieder die z'n e-mailadressen nog niet heeft opgegeven, doe het: je krijg een mailtje als er een breach is met jouw opgegeven e-maildres. Erg praktisch en goed voor je veiligheid

[Zenomyscus]

Tja, dan sta ik daar weer in een database. Laat maar.

- Ik zorg voor unieke wachtwoorden, voor elke site. Eventueel kun je een password manager gebruiken, maar ook dat zie ik als een risico.
- Met eigen domeinnamen regel ik unieke emailadressen, altijd leuk om te zien welke adressen ineens spam veroorzaken.
- Regelmatig laat ik emails bouncen op adressen die ik op dat moment niet nodig heb. Geen idee of dat ook werkt tegen spammers.

Eigenlijk gaat er vrij weinig mis, ik meld me ook zelden voor iets aan. Eerst kijken of ik het echt wil voordat ik weer een mailadres rondstrooi. Hetgeen wat ik wel vervelend is de spam op het adres waar ik domeinen mee registreer. "Hello my name is Rayesh, I build very good websites for you"

[lepel]

Het is goed dat jij jezelf op deze manier veilig houdt, maar je snapt natuurlijk ook wel dat dit voor de gemiddelde medemens onmogelijk is.

Mijn gegevens hebben ondertussen in 16 hacks gezeten en 7 keer op pastebin gestaan. Dan vind ik het wel handig dat ik een mailtje krijg wanneer mijn emailadres weer eens tussen een hack zit. Klopt, het staat dan in nóg een database, maar ik vind het niet zo erg wanneer alleen mijn emailadres naar buiten komt, gelukkig heeft Hotmail goede spamfilters.

[Cerberus_tm]

Ik snap ook echt niet waarom je voor *elke* site een ander wachtwoord zou willen. 99% van de accounts zijn totaal onbelangrijk. Wat kan mij het schelen als mijn Disqus-account gestolen wordt, dan maak ik toch een nieuwe? Of een van de 200 fora waar ik wel eens een account gemaakt heb? Of een willekeurige webshop? Als ik mijn Amazon- of Tweakers-account kwijtraak, overleef ik dat ook wel. Alleen dingen waar je echt geld in geïnvesteerd hebt, zoals de Play Store, Steam, of Paypal, of je hoofd-email-account, of de inlog van een website die je zelf beheert, dat zou erg zijn. Voor die 20 accounts kun je dan elk apart een moeilijk wachtwoord aanmaken, en liefst ook 2FA. Daarbeneden heb ik een aantal sites "2e klasse" zoals de meeste webshops met betaalgegevens: vervelend, maar geen ramp als ik die kwijtraak. Die kun je allemaal hetzelfde wachtwoord geven. Alle andere sites zijn 3e klasse en hebben zoveel mogelijk hetzelfde wachtwoord. Veel plezier daarmee. Daar is er wel eens eentje van gelekt, maar ik ga dan echt niet al mijn wachtwoorden veranderen. Laat maar lekker hacken.

[Reactie gewijzigd door Cerberus_tm op 24 juli 2024 19:09]

[lepel]

Zelfde redenering die ik gebruik. Ik heb zelf een drietal wachtwoorden die ik gebruik op basis van hoe belangrijk iets voor mij is. Registreer ik me op een of ander klein nietszeggende forum dan gebruik ik gewoon het wachtwoord dat nu al 16 keer is uitgelekt. Word een belangrijke website gehackt, dan is het gewoon het rijtje af gaan en wachtwoorden veranderen.

Geen enkele "hacker" die dat wachtwoord in hande heeft en zulke websites gaat meenemen in een poging om op mijn accounts binnen te komen. Facebook, Ebay, Twitter, PayPal, die wel ja, maar het ASNgaming.net forum? En zouden ze nog binnen komen, er valt daar niks te halen.

[Reactie gewijzigd door lepel op 24 juli 2024 19:09]

[GeroldM]

Deze gegevens kunnen in principe gebruikt worden om toegang te krijgen to andere online accounts. Ze kunnen ook inzicht geven over hoe jij jouw accounts hebt beschermd. Kraakpogingen worden dan daarop aangepast.

Mocht men dan een patroon ontdekken, dan kan men aan het patroon zien welke software jij gebruikt voor je wachtwoorden. Nu heeft men genoeg info om jou en jouw beveilgingssysteem extreem doelgericht aan te vallen.aan te vallen.

Goed, dat soort moeite word alleen gedaan in speciale gevallen, je hoeft dit niet te verwachten bij standaard kraakpogingen.

Ik wil alleen maar aangeven dat met met genoeg metadata, er al uitgebreide conclusies getrokken kunnen worden om jouw accounts specifiek aan te vallen. Met alle (fysieke, financiele en mentale) gevolgen van dien.

[Cerberus_tm]

Theoretisch heb je gelijk. Maar er er geen (realistisch) patroon tussen klasse 1, 2, en 3. Die vallen niet uit elkaar af te leiden. Verder gebruik ik geen software om mijn wachtwoorden te maken; dat doe ik zelf. Maar sowieso zou ik Lastpass daar wel mee vertrouwen, zo'n willekeurig wachtwoord is echt niet te kraken.

[Reactie gewijzigd door Cerberus_tm op 24 juli 2024 19:09]

[OddesE]

Een simpele oplossing is een basis wachtwoord en daar bijvoorbeeld de eerste 3 letters van de website aan toe voegen.

Bijvoorbeeld het basis wachtwoord is s3cret en dan voor tweakers: s3crettwe.

Eenvoudig om te onhouden, maar veel lastiger voor tools om er achter te komen wat je wachtwoord op een andere site is als ze die van de ene site hebben.

[Cerberus_tm]

Op zich handig. Maar volgens mij is deze truc (of varianten daarop) wel bekend, dus ook aan hackers!

[OddesE]

Als een hacker een gerichte aanval gaat doen op de account van OddesE of Cerberus_tm dan zal die wellicht wel wat gaan proberen en er achter komen ja.

Maar het grootste risico met dit soort hacks is dat men de gevonden passwords even gaat gebruiken om te proberen in te loggen bij de mail service die bij het opgegeven e-mail adres hoort. En dat kun je een tool geautomatiseerd laten doen. Dus even voor elk gevonden wachtwoord testen of je daarmee ook in de mail kunt komen en zo ja, komt het account op een shortlist terecht. En pas dan komt de hacker er aan te pas. Want die gaat echt niet met de hand miljoenen accounts door ploegen.

Een simpele truc als die ik beschrijf beschermt zeer effectief tegen dat probleem en zorgt ervoor dat je jezelf niet volledig overlevert aan elke site waar je je op inschrijft.

[Cerberus_tm]

Nou, ik ben geen expert, maar vergis je niet: er is allerlei kraaksoftware met slimme algorismes. De eerste paar letters van een site achter een bestaand wachtwoord zetten zou best een module kunnen zijn van zo'n kraakprogramma. Maar je hebt gelijk dat we het dan hebben over een partij die tenminste meerdere pogingen aan het ondernemen is om op ons account in te loggen. De snodaard!

[OddesE]

Het gaat er niet zozeer om dat het zou kunnen (dat is zo natuurlijk) maar vooral dat je het veel moeilijker maakt.

Hetzelfde wachtwoord proberen is natuurlijk de eerste optie. Maar als die faalt, wat dan. De eerste 3 letters klinkt simpel, maar het zouden er ook twee kunnen zijn. Of vier. Of de hele domeinnaam. Of misschien zet je ze vooraan of achteraan... Het aantal combinaties explodeert onmiddellijk en dus heb je het al snel over vele duizenden of tienduizenden pogingen in plaats van 1 poging. En dan krijg je meteen te maken met de beveiliginsfeatures van grote webdiensten zoals GMail... Ze gaan je pogingen throttelen, je vragen een captcha in te vullen, de eigenaar van het account krijgt een notificatie van de inlog pogingen enz.

Daarom is het zo belangrijk om gewoon een simpel systeem voor jezelf te verzinnen dat je makkelijk kunt onthouden en dat toe te passen. Kost je heel weinig moeite maar levert een gigantisch groot voordeel op. Nogmaals het wordt er niet onkraakbaar van natuurlijk. Maar het verhoogt de drempel dermate dat men al snel verder gaat naar het volgende slachtoffer en jij dus niet in de problemen komt. En daar gaat het om.

[Cerberus_tm]

Dat is waar, voor het inloggen van een afstand kan het genoeg zijn (maar dus niet als je de hash hebt buitgemaakt en die probeert te kraken). In bepaalde omstandigheden werkt 'security through obscurity' best goed.

[418O2]

Je kan ook andere eigenschappen dan de naam nemen en een vaste post en prefix gebruiken

[OddesE]

Ja precies. De moraal van het verhaal: verzin een systeem waardoor voor jou, en alleen voor jou, het heel makkelijk wordt om op elke website een uniek wachtwoord te gebruiken. Pas dat systeem vervolgens toe en je bent meteen honderd keer veiliger dan de gemiddelde internetter. En aangezien de hackers allereerst de makkelijke slachtoffers pakken ben je daarmee gewoon heel veilig.

[Sleurhutje]

Zelfs emailadressen met jaar/maand erin zodat je ook nog weet hoeveel tijd er gewacht wordt met doorspelen van info.

Het blijft leuk om email voor [e-mail] te krijgen van een tuindecoratie toko. Heeft in ieder geval een leuke korting bij de volgende boeking opgeleverd door iets onaardigs te zeggen over het niet respecteren van hun eigen voorwaarden.

[iAR]

Tja. Ik heb daar ook over na zitten denken. Zo'n catch all domein heeft alleen niet iedereen. Mensen hebben vaak gewoon gmail. En ook al kun je daar emailadressen uniek maken, volgens mij doen weinig mensen dat.

De database is overigens wel email only.

[Verwijderd]

Jammer dat hij bij Gmail in de spam terechtkomt, althans bij mij..

[Soldaatje]

Wordt het misschien niet tijd om niet alleen wachtwoorden maar alles in een database te hashen?
Er zitten toch email-adressen bij, die zijn toch wel belangrijk genoeg om misbruik door phising en spam tegen te gaan?

Edit: ok, hashing is 1-weg, dat kan niet. Maar encryptie dan?

[Reactie gewijzigd door Soldaatje op 24 juli 2024 19:09]

[Aaargh!]

Wordt het misschien niet tijd om niet alleen wachtwoorden maar alles in een database te hashen?

Hashen is 1-richting, dus je hebt er niks aan voor gegevens die je nog moet kunnen uitlezen. Je kan wel een gehashed email adres opslaan, maar daarmee kan je iemand geen email sturen.

[GateKeaper]

Wat ik opzich weer toejuich. Veel websites hebben mijn email echt niet nodig, maar vragen er toch om.

Maar inderdaad, een platform als deze heeft je email nodig om notificaties te sturen. Niet (alleen) om in te loggen.

Zou het enkel om de inlog zijn, dan kan je het emailadres inderdaad ook hashen.

[Eagle Creek]

Als ze je wachtwoord niet mogen bewaren en ook je emailadres niet wordt het een andere methode bedenken voor de "lost my password"-procedure. Zal vast iets voor mogelijk zijn maar dat moet dan weer grootschalig worden geïmplementeerd.

En laten we eerlijk zijn: de mogelijkheid om je gebruikers actief te benaderen is commercieel gezien erg waardevol.

[gday]

Zo moeilijk zou dat niet moeten zijn als je het mailadres ook gehasht opslaat.

Je laat iemand een mailadres invullen en verstuurt een link naar een formulier naar dat mailadres. Dan vult de gebruiker dat in, je onthoudt de hash van het mailadres (eventueel als parameter in de link), en koppelt de hash van het wachtwoord aan de hash van het mailadres. Moet geen probleem zijn toch?

[mrdemc]

Lijkt mij ook geen probleem en vraag me eigenlijk ook af waarom gebruikersnamen of e-mailadressen sowieso niet encrypted danwel gehashed opgeslagen worden. Encrypted in het geval je het nodig hebt voor gebruik van een nieuwsbrief bijv. Maar dan kun je het nog in een aparte tabel encrypted opslaan. Puur voor login gebruik zou het inderdaad prima kunnen zoals jj aangeeft. Als de gebruiker z’n mailadres invult heb je tenslotte het origineel van de hash in het geheugen waar je het ww-vergeten naartoe stuurt. De koppeling van welk account t is match je dan op de hash. Prima oplossing en zou al een hoop schelen.

[Laloeka]

Encryptie is alleen nuttig tegen hacks die direct toegang krijgen tot de bestanden op de database server. De meeste lekken gebeuren via APIs en andere lekken in de applicatie, waar dit geen extra beveiliging factor oplevert, terwijl er wel extra resources nodig zijn.

[mrdemc]

Wel als je de encryptiesleutel functie afhankelijk maakt. Een lek in een andere functie zal dan alleen toegang krijgen tot versleutelde data. Als je dan ook een scheiding maakt in de rechten voor de functie die wegschrijft en die de data uitleest maak je de impact nog kleiner.

[R4gnax]

Zou het enkel om de inlog zijn, dan kan je het emailadres inderdaad ook hashen.

Nee, dat kun je niet. Want hashes kunnen collisions hebben.

[Devaqto]

SHA-2/3 collision is nog niet voorgekomen.

[R4gnax]

SHA-2/3 collision is nog niet voorgekomen.

Een gecontroleerde collision niet, nee.

Maar als je een e-mail adres als unieke identificatie voor een gebruiker wilt gaan hanteren, dan heb je geen gecontroleerde collision nodig, maar volstaat in principe elke om een probleem te krijgen met de data-integriteit van accountgegevens.

[Reactie gewijzigd door R4gnax op 24 juli 2024 19:09]

[MSalters]

En wat dan nog? Datzelfde geldt voor gehaste passwords.

Vergeet niet dat je vanwege de salt niet eens kunt zeggen dat identieke hashes ook identieke email adressen betekenen.

[R4gnax]

En wat dan nog? Datzelfde geldt voor gehaste passwords.

Vergeet niet dat je vanwege de salt niet eens kunt zeggen dat identieke hashes ook identieke email adressen betekenen.

Een hash collision op een password is van een heel andere aard. Je moet dan bewust een collision gaan opzoeken voor het wachtwoord van één specifieke gebruiker.

Een hash collision op de login naam / e-mail adres is al een probleem als je een collision met één willekeurige andere gebruiker in het systeem hebt.

In het slechtste geval betekent dit dat je data-integriteit sneuvelt en je twee fysieke gebruikers op één account schuift, met alle privacy-schendende gevolgen van dien. In het minst erge geval kan Pietje via zijn e-mail adres geen account aanmaken omdat Henk al een account heeft en de hashes samenvallen, en loop je zo misschien een klant mis die het elders wel gaat proberen.

[Reactie gewijzigd door R4gnax op 24 juli 2024 19:09]

[MSalters]

Huh? Hoe kom je daar nou weer bij? Je wil toch niet zeggen dat je de gehashte email als unique key in een database wil gebruiken?

Het is niet onredelijk om een index op de " HashedEmail" kolom te leggen, maar het is onzinnig om dat een unique key te maken. En als je dat de Primary Key maakt van je gebruikertabel, dan is er iets héél fout gegaan in je database cursus.

Nee, HashedEmail conflicten zijn net zo ernstig als DateOfBirth conflicten. Je moet een fundamentele ontwerpfout maken wil je daardoor gebruikers uitsluiten.

[R4gnax]

Huh? Hoe kom je daar nou weer bij? Je wil toch niet zeggen dat je de gehashte email als unique key in een database wil gebruiken?

Het is niet onredelijk om een index op de " HashedEmail" kolom te leggen, maar het is onzinnig om dat een unique key te maken. En als je dat de Primary Key maakt van je gebruikertabel, dan is er iets héél fout gegaan in je database cursus.

Nee, HashedEmail conflicten zijn net zo ernstig als DateOfBirth conflicten. Je moet een fundamentele ontwerpfout maken wil je daardoor gebruikers uitsluiten.

Als je mensen met hun e-mail in wilt kunnen laten loggen, dan is dat best wel een primary key...

[MSalters]

Op zich is unique key dan voldoende (een tabel kan meerdere unique keys hebben, maar er is maar 1 primary key). Maar dan wil je uberhaupt geen hashed email adressen hebben, collisions of niet. het probleem is dat je op basis van de email de user row wil ophalen, met daarin de salt die gebruikt is voor de hashes. Je ziet nu meteen de circulaire logica: de salt kun je alleen ophalen op basis van een kolom die niet afhankelijk is van die salt.

[svenk91]

Tijdelijk het wachtwoord bewaren voor een verificatie mailtje, en daarna enkel gehashed opslaan voor inloggen zou voor mij bij veel sites wenselijk zijn.

Sowieso een aanrader om niet hetzelfde e-mail voor belangrijke en minder belangrijke sites te gebruiken. Mijn e-mail geregistreerd bij tweakers staat vol met spam, en ik ben er zeer kritisch als er iets gevoeligs via dat adres gevraagd wordt.

[Verwijderd]

Eens. Eigenlijk zou je met elektronische ID's net zo om moeten gaan als IRL id's. Bijv. als je je moet legitimeren voor echt belangrijke dingen, dan gebruik je je paspoort. Maar als je naar de sportschool gaat, gebruik je niet je paspoort om naar binnen te komen, maar een pasje van de sportschool (als daar wat mee gebeurt is de impact niet zo groot). Dat is in feite net zoiets als verschillen elektronische ID's. Maar goed, hoe breng je mensen aan het verstand dat ze zo met internet om moeten gaan. Veel mensen hebben nog steeds niet door dat je ook een emailadres dat niet door je ISP is gegeven kunt gebruiken en raken in paniek als ze overstappen naar een andere provider.

[mikesmit]

Op het moment dat je data hashed word het onbruikbaar. Dan kan je het enkel nog voor verificatie gebruiken omdat je nooit meer het origineel kan achterhalen.

[Laloeka]

De database versleutelen klinkt als een extra beveiliging, maar dat heeft een aantal nadelen:

- het is niet mogelijk om een snelle database te maken met enkel versleutelde data
- jouw accountgegevens zijn ook nodig als je niet ingelogd bent, dus Disqus moet de sleutel hebben
- als de sleutel in het gekraakte systeem zit, is de database effectief niet versleuteld voor de hackers, ze hebben immers toegang tot de sleutel.

Wat je zelf kunt doen:
- een password manager gebruiken en elk account een unieke, willekeurig wachtwoord geven
- zo min mogelijk persoonsgegevens invullen. Vaak is je geboortedag of woonplaats niet eens vereist.
- een uniek e-mail adres per account gebruiken (vereist een 'catch-all' email setup en een eigen domein)
- goed nadenken of het echt nodig is een account te maken. Vaak kun je ook kiezen om via Twitter/Steam/Facebook in te loggen. Let wel op welke rechten je aan de service geeft waarop je inlogt, soms plaatsen deze dan automatisch berichten op je account of lezen ze je hele Steam profiel uit.

[Verwijderd]

Voor unieke email adressen hoef je niet per se een catch-all te doen. Je kunt ook meerdere (bijvoorbeeld) gmail adressen nemen en die allemaal configureren in de email client. Is het ook meteen netjes gestructureerd.

Voor de rest ben ik het helemaal met je eens. Eigenlijk komt het er op neer dat mensen eens gaan nadenken over waar ze mee bezig zijn. Je ziet mensen af en toe dingen op internet doen die ze in het echte leven echt nooit zouden doen. Bijvoorbeeld zomaar bij een onbekende winkel voor ik weet niet hoeveel geld spullen bestellen. Als ik op de hoek van de straat met een kraampje ga staan doen die mensen dat echt niet.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 19:09]

[Origin64]

Inloggen op allerlei services met 1 facebook of google of steam login is alleen maar gevaarlijker. Als dan die service gehackt wordt ben je op heel veel plekken kwetsbaar.

En disqus heeft helemaal jouw keys niet nodig, dat is alleen nodig als ze je prive data willen verkopen.

[MrMarcie]

Vroeg bij mij niet om een PW. Toch maar even gewijzigd.

[gandalf300]

even voor de duidelijkheid, het gaat hier alleen om accounts die al sinds 2012 of daarvoor bestaan. na 2012 zijn ze van SHA1 naar bcrypt gegaan, die accounts hebben hier dus geen last van.

[xiphoid]

Ik zat ook in de database volgens Troy, maar mijn account is uit 2014 and 2015.
Toch beetje raar, misschien dat iemand ooit geprobeerd heeft een accountje te maken met mijn email (en nooit verified)

[MrSnowflake]

En… we vinden het allemaal ok dat ze hier pas 5 jaar later mee naar buiten komen? Op die 5 jaar hebben de hackers heel wat tijd gehad om wachtwoorde te achterhalen.

[[Yellow]]

+1 Vind ik ook.
Vanwege de lange tijdsduur voordat ze ermee naar buiten kwamen vind ik deze hack bijna net zo erg als die van Equifax... Boetes voor bedrijven die niet uit zichzelf naar buiten komen met informatie zou je bijna een goede maatregel gaan vinden (bijna dan).

[Reactie gewijzigd door [Yellow] op 24 juli 2024 19:09]

[MSalters]

Als je de links gevolgd hebt: "The theft was only discovered this week". Ja, hackers hebben 5 jaar de tijd gehad, maar ze hebben het dus binnen een week na ontdekking gedeeld. En dat is een redelijke termijn om intern eerst de huidige beveiliging te checken.

Overigens is er nog geen informatie bekend dat hackers ook daadwerkelijk iets met die informatie gedaan hebben. Noch in de afgelopen week, noch in de 5 jaar daarvoor.

[Verwijderd]

Ik begin mij steeds meer af te vragen wie nog NIET gehackt is.