Accountgegevens buitgemaakt bij hack en ransomwareaanval OpenSubtitles.org

De accountgegevens en wachtwoorden van 6,7 miljoen gebruikers van OpenSubtitles.org zijn in augustus 2021 gelekt na een hack en ransomwareaanval. Pas nu heeft de website dit aan gebruikers verteld. De gegevens zijn inmiddels toegevoegd aan Have I Been Pwned.

In een forumpost leggen de admins van de site uit dat zij in augustus 2021 benaderd zijn door een persoon die toegang had tot gebruikersgegevens. Hij vroeg een dwangsom om de gegevens te verwijderen en niet te openbaren. De aanvaller had toegang tot de inloggegevens, e-mailadressen, IP-adressen, land van herkomst en ontsleutelde wachtwoorden van in totaal 6.783.158 accounts. Die inloggegevens zijn toegevoegd aan de wachtwoorddatabase van Have I Been Pwned.

De admins van OpenSubtitles.org leggen uit dat de wachtwoorden versleuteld waren met md5-hashes zonder salt, waardoor korte wachtwoorden makkelijk ontsleuteld konden worden. De aanvaller kreeg toegang tot de site door een slecht beveiligde SuperAdmin-account en een onbeveiligd script. Hierdoor kon de aanvaller SQL-injecties uitvoeren en de data stelen.

Volgens de admins hebben zij 'amper' gehoor gegeven aan de ransomware-eis, omdat het geldbedrag te hoog was. Wat dat precies betekent leggen zij niet uit. Wel vertellen ze dat de aanvaller hen heeft geholpen de site beter te beveiligen door uit te leggen waar de kwetsbaarheid zat. Ook had hij beloofd de buitgemaakte data te verwijderen. De harde les die de admins naar eigen zeggen hebben geleerd is dat de beloftes van een aanvaller niets waard zijn, omdat hij alsnog de wachtwoorden openbaar gemaakt heeft.

Volgens de admins heeft de hacker geen toegang gekregen tot creditcardgegevens van gebruikers, omdat die extern opgeslagen zijn. Wel heeft hij toegang gekregen tot accounts, met name die met korte of slechte wachtwoorden, omdat die makkelijk te ontsleutelen zijn. De site raadt aan het wachtwoord aan te passen. Daarnaast heeft het de beveiliging inmiddels verbeterd.

Reacties (108)

De harde les die de admins naar eigen zeggen hebben geleerd is dat de beloftes van een aanvaller niets waard zijn

Nog even los van hun eigen waardeloze security kennis blijkbaar, de aanval is hier echt bijzaak. Md5 is al mijn-eerste-PHP+Mysql-website niveau, salt of niet (want die salts lekken toch vaak uit als het gehele systeem compromised is).

want die salts lekken toch vaak uit als het gehele systeem compromised is

Het idee is niet dat salts geheim blijven als de wachtwoordhash uitlekt. Het idee is dat je niet alle wachtwoorden tegelijk kunt kraken, omdat elk wachtwoord een lange unieke tekenreeks bevat. Het voorkomt ook het gebruik van vooropgezette rainbowtables.

[Reactie gewijzigd door .oisyn op 19 januari 2022 11:50]

Indien men inderdaad unieke salts gebruikt, maar ook dat is zeker niet een automatisch gegeven, zoals bij eerdere datalekken is gebleken (als men al beroerde keuzes maakt zijn vaak meerdere keuzes beroerd)... Een tweede aspect van unieke salts wat je niet noemt trouwens is dat het ook hashfrequentie maskeert, dus dat je niet kan zien welke wachtwoorden het populairst zijn en die als eerste proberen te kraken. Wat vaker de insteek is dan per se de hele database kraken, want er zijn tegenwoordig vaak genoeg users met behoorlijke wachtwoorden uit wachtwoordmanagers die en lang zijn (kost relatief te veel tijd) en toch al uniek voor de account zijn en dus nutteloos om te distribueren, je zoekt dus meestal naar de kinderachtige wachtwoorden die ergens anders ook kans hebben om bruikbaar te zijn.

Maar specifiek voor md5 vraag ik het me af of zelfs unieke salts nog een probleem zouden zijn voor het kraken, want gezien de praktische hashrates tegenwoordig moet je wel enorme salts hebben om brute force onpraktisch te maken. En dan rijst de vraag hoe iemand wel op dat idee zou zijn gekomen en niet om een beter hashalgo te gebruiken.

[Reactie gewijzigd door The Third Man op 19 januari 2022 12:08]

Indien men inderdaad unieke salts gebruikt, maar ook dat is zeker niet een automatisch gegeven, zoals bij eerdere datalekken is gebleken (als men al beroerde keuzes maakt zijn vaak meerdere keuzes beroerd)...

Uiteraard, maar dat is wat een salt is, anders is het feitelijk een pepper: een (niet per se unieke) waarde die niet bij het wachtwoord staat opgeslagen.

[Reactie gewijzigd door .oisyn op 19 januari 2022 13:17]

Daarom ook belangrijk om voor sites unieke wachtwoorden te hebben. Bij voorkeur random gegenereerd.

En 2FA op alle belangrijke zaken.

Dit is slecht beveiligd, maar dit niveau is helaas niet bijzonder.

[Reactie gewijzigd door Keypunchie op 19 januari 2022 10:03]

Daarom ook belangrijk om voor sites unieke wachtwoorden te hebben. Bij voorkeur random gegenereerd.

Voeg daar aan toe: een separaat emailadres per dienst; kleine moeite, wel een extra isolatie in geval van lekken.

Is voor de niet IT'er vaak redelijk lastig. Bedoel je hiermee bijvoorbeeld 10 gmail adressen of iets in de richting van een catch-all?

Een eigen domein + een catchall is het makkelijkst. Niet triviaal te verkrijgen voor een leek. Maar vergt zeker geen uitgebreide IT kennis. Er zijn genoeg mail providers die je makkelijk je eigen domein laten configureren.

Voor leken is er tegenwoordig "sign in with apple" die unieke emailadressen genereert. Hopelijk komt Google ook op een gegeven moment met die service voor Gmail.

Als alternatief heb je wel Firefox Relay, maar dat is een los, betaald abonnement als je meer dan vijf adressen wil gebruiken. Het is dan wel weer een losstaande service, wat weer goed kan zijn (bijvoorbeeld als Apple of Google zonder verklaring je account sluiten, dan kun je je mail in elk geval nog gebruiken).

Ook Protonmail heeft hier geloof ik een dienst voor, maar ik ben niet bekend met de mate van integratie die daar geboden wordt.

Het kan allemaal zonder eigen domein, maar als je het zelf niet opzet, zul je waarschijnlijk moeten gaan betalen (danwel een abonnement, danwel de Apple-taks).

Is voor de niet IT'er vaak redelijk lastig. Bedoel je hiermee bijvoorbeeld 10 gmail adressen of iets in de richting van een catch-all?

Er tussenin; thuis hebben we 'allemaal' ons eigen domein. We draaien Yunohost als platform, ik heb m'n kinderen aangeleerd om, als ze zich ergens voor inschrijven, daar een emailadres voor aan te maken.

Een catch-all heeft het nadeel dat alles binnenkomt, een spammer op [e-mail] krijgt dan geen fout terug en blijft lekker spammen.

De '+' die @Caayn noemt helpt vooral voor jezelf om je email makkelijk in bakjes te kunnen gooien, maar ik merk dat er in het wild best wat mailservers (Exchange, looking at you) zijn die mailstandaards niet volledig implementeren.

De eenvoudigste implementatie die ik ken is 'verberg mijn emailadres' van Apple:
https://www.iculture.nl/tips/emailadres-verbergen/

Zeker voor niet-ITers werkt dit perfect (maar ik gebruik het zelf ook voor een aantal onbelangrijke dingen).
1Password biedt deze functionaliteit ook aan en ik denk dat ze niet de enige zijn.

Als gratis alternatief zit je aan Gmail Taakspecifieke e-mailadressen. Dit werkt volgens mij ook bij Outlook.com en Yahoo. Kies je datagraaier maar de meeste mensen hebben toch al ergens een account.

Catch-all adressen zijn leuk tot de spammers je domein vinden. Vroeg of laat geef je het dan toch op want de hoeveelheid (niet-bouncende) email kan je niet aan. Ik zie zelf regelmatig logs langskomen dat men email systemen 'probed' met grote reeksen 'aan' adressen.

Als je dat doet realiseer je dan wel dat het kinderspel is om de bekende "+" trucjes ter herkennen en te strippen.

In iOS kun je tegenwoordig zelf snel aliassen aanmaken die worden doorgestuurd. Werkt prima, ik neem aan dat Android zoiets ook wel heeft

Geen idee. Ik weet wel dat outlook/MS dit ook ondersteunt, ik maak er al jaren gretig gebruik van

Klopt. Ik zou graag zien dat Google voortaan ook een zelf in te stellen tekst zou accepteren.

Veel sites accepteren [e-mail] niet en spammers kunnen zoals je zegt eenvoudig alles tussen + en @ verwijderen.

Als ik zelf iets kon verzinnen zouden beide problemen opgelost worden en als google alleen ‘labelthissenderwith’ zou accepteren in elk geval het eerste probleem.

ik zie het nut niet zo. Stel je voor ik zit op site X. Dan gaat het mis met die site. Mijn emailadres daar kan je doorgaans lastig wijzigen.

Ik wil nog steeds communicatie van die site ontvangen, dus ik kan ook het emailadres niet afsluiten.

Wat bedoel je met 'dit niveau'? Nu komt het namelijk over als een denigrerende opmerking...

EDIT:
Het bericht is al iets genuanceerder en duidelijker. Het is inderdaad best spijtig dat er websites zijn die hun wachtwoorden nog op zeer ouderwetse manieren opslaan en daarbij dus scripts hebben die gewoon gigantische gaten bevatten, terwijl er tegen beveiligen echt zo moeilijk niet is.

[Reactie gewijzigd door CH4OS op 19 januari 2022 10:39]

Vermoedelijk doelt hij op het niveau van beveiliging van OpenSubtitles, MD5 hashing wil je al jaren niet meer gebruiken.

Dat een dergelijke site alsnog MD5 hashing gebruikt laat wel zien dat 'dit niveau' [van beveiliging] nog steeds voorkomt en derhalve niet bijzonder is, helaas.

Yep, I know. Bij PHP kun je zelfs de hashing van passwords dynamisch maken en automatisch laten omzetten naar de default hashing algoritme van die specifieke PHP-versie, dan ben je er voor eens en voor altijd van af.

Wat bedoel je met 'dit niveau'?

MD5 hashing voor wachtwoorden is al meer dan 10 jaar achterhaald.

https://www.kb.cert.org/vuls/id/836068 (let op de publicatiedatum)
Hun advies:
"Do not use the MD5 algorithm
Software developers, Certification Authorities, website owners, and users should avoid using the MD5 algorithm in any capacity. As previous research has demonstrated, it should be considered cryptographically broken and unsuitable for further use."

Ik weet dat MD5 hashing voor passwords not done meer is, maar mij was even onduidelijk waar je op doelde met 'dit niveau', nadat je jouw bericht aangepast had was dat al duidelijk, thanks voor de extra toelichting en het linkje!

En 2FA op alle belangrijke zaken.

2FA is alleen een serverside controle of je door mag in het inlogproces. 2FA heeft in deze gevallen geen zin, tenzij je dat écht overal gebruikt. De meeste (van dit soort) sites ondersteunen helaas niet tot nauwelijks 2fa.

Wat ik hieronder lees, deed ik ook. Op opensubtitles gebruik(te) ik ook een heel simpel wachtwoord. Dit puur omdat het inloggen op Kodi (via afstandsbediening) waardeloos gaat. Ik ben dan ook echt fan van services die een QR op het scherm gooien (of een code) om vervolgens via de telefoon in te loggen.

Hoezo heeft het geen zin? Het gaat niet om *deze* site, het gaat erom dat als je ergens anders dit wachtwoord hebt hergebruikt, dat men daar toch er niks mee kan!

Ik doelde op dit soort wachtwoordlekken, ze voorkomen de lekken niet.

Wat ik hieronder lees, deed ik ook. Op opensubtitles gebruik(te) ik ook een heel simpel wachtwoord. Dit puur omdat het inloggen op Kodi (via afstandsbediening) waardeloos gaat. Ik ben dan ook echt fan van services die een QR op het scherm gooien (of een code) om vervolgens via de telefoon in te loggen.

Op zich maakt het soort wachtwoord (makkelijk, moeilijk...) niet heel veel uit dat je zelf gebruikt, daar heb je immers uiteindelijk alleen jezelf mee (en een risico afweging gedaan natuurlijk ). Maar dat betekend niet dat degene die de data opslaat, de gegevens (zeker gevoelige informatie zoals inloggegevens) niet veilig hoeft op te slaan. Dat is anno 2022 echt een must.

Plus een domein met een catchall email. [e-mail] & [e-mail] etc.

Niet vergeten om dan je domein te verlengen, anders hebben ze toegang tot ál je accounts ;-)

Moeten ze nog het e-mail adres weten ;-) Maar idd, dat zou wel treurig zijn.

Vooral met dit soort websites, dus ook torrent forums en dergelijke, moet je nooit een belangrijke e-mailadres gebruiken. Je weet ten eerste niet wie de website beheert en zelfs als ze geen kwade bedoelingen hebben kan je hen niet vertrouwen of ze hun beveiliging op orde hebben. En het trucje met de + teken helpt niet als je email door een slimme crimineel is verkregen. Gewoon een extra Gmail adresje aanmaken met een nep naam en een unieke wachtwoord. Dus als die account gehackt is dan is er geen persoonlijke info buitgemaakt.

Ah, op die manier. Maar dat is iets anders dan een uniek emailadres per site. Ja, ik heb een rommel-emailaccount voor de verplichte registraties van sites waar ik niet om geef.

Overigens vind ik ook dat nog wel gedoe.

2fa werkte ook lekker bij de hack van crypto. Com

Na een password reset kreeg ik mijn tijdelijke password in plain text in de e-mail...

Hoe wil je anders een tijdelijk wachtwoord ontvangen?

Of bedoel je een wachtwoord wat je zelf had ingevoerd?

Hoe wil je anders een tijdelijk wachtwoord ontvangen?

Dat je een link ontvangt, waardoor je naar een pagina van de site wordt gestuurd waar je vervolgens je nieuwe wachtwoord in kan voeren.

En wat denk je dat er in die link staat?

Opensubtitles heeft het wel knullig geimplementeerd. Ze sturen je in plain-text een wachtwoord, maar dat nieuwe wachtwoord moet je wel eerst activeren door op een link te klikken welke in hetzelfde mailtje staat.
Maar daarna wordt je niet gevraagd om zelf een nieuw wachtwoord in te stellen.

Ik had trouwens niet anders verwacht van deze website . Hun gehele website ziet er nogal knullig uit. Maar wat had je anders verwacht van een website die volledig bestaat op basis uploads van gebruikers?

Geen wachtwoord 😉. Daar staat vaak enkel een single-use token in en een account identifier. Zo kunnen ze controleren of je token ook echt bij het account hoort waarvoor een reset is aangevraagd. En omdat ze de link naar je email sturen is de gehele procedure dus relatief veilig.

[Reactie gewijzigd door Gody op 19 januari 2022 10:15]

Een hash en geen tijdelijk wachtwoord om mee in te loggen.

Twee lege velden: één om je nieuwe wachtwoord in te vullen en de ander voor bevestiging.

In de link / URL zit een tijdelijk wachtwoord (of andere authenticatie token) embedded. Die wordt dus ook in plain text verstuurd.

Nee, waar haal je vandaan dat het plain-text verstuurd wordt en dat de URL je tijdelijke wachtoord bevat (dat is niet bij alle implementaties zo)? We hebben het over je nieuwe wachtwoord instellen.

[Reactie gewijzigd door AnonymousWP op 19 januari 2022 10:11]

De code in de URL is effectief een tijdelijk wachtwoord

Maar wel eentje die bijv. binnen 10min. verloopt. Een tijdelijk wachtwoord is daarentegen geldig totdat de gebruiker zelf zijn/haar wachtwoord gewijzigd heeft.

Onzin, een tijdelijk wachtwoord kan ook gewoon na een bepaalde tijd verlopen.

Je hebt het waarschijnlijk over een token (tijdelijk geldig), en tokens worden heel veel gebruikt. Ervan uitgaande dat emails wél veilig verstuurd worden, is er in principe niet direct een probleem. In dit geval werden wachtwoorden onveilig opgeslagen, dus zou het überhaupt niet veel uitmaken. Als de website zelf wel redelijk veilig was, hoeft het instellen van een nieuw wachtwoord geen probleem te zijn.

[Reactie gewijzigd door AnonymousWP op 19 januari 2022 10:19]

Nou ja, ook niet helemaal. Een token kan bv na 10 minuten verlopen. Ook kan je aan een token hangen dat hetzelfde IP adres de token moet opvragen als uitvoeren. Met een tijdelijk wachtwoord wat gewoon in de database geplempt wordt heb je dergelijke beveiliging niet.

Maar hoe weet die pagina dat jij degene bent die je wachtwoord mag veranderen? Dat komt omdat er iets in de email zit wat meegegeven wordt aan de webpagina. Dat is in feite een tijdelijk wachtwoord

Dat is in feite een tijdelijk wachtwoord

De nuance is hier heel belangrijk. Het is geen tijdelijk wachtwoord, want het overschrijft je bestaande wachtwoord niet. Het is een tijdelijke token waarmee je je wachtwoord kan wijzigen. Dit is belangrijk, want dat voorkomt dat iemand voor iemand anders zomaar zijn wachtwoord reset. Als ik voor jou een daadwerkelijk tijdelijk wachtwoord kan aanvragen, dan kan jij niet meer inloggen zonder eerst naar je mail te kijken, en is dus een soort denial of service attack.

@nandervv Slaat imho dan ook de plank mis.

[Reactie gewijzigd door .oisyn op 19 januari 2022 11:41]

Zo'n tijdelijk wachtwoord is juist handig als alle wachtwoorden op straat liggen, toch?

Een tijdelijk token*. En wat is daar precies mee? Jij weet of die pagina wel of niet veilig was? Misschien was die pagina wél veilig genoeg en is er niks aan de hand als jij je wachtwoord opnieuw instelt via die pagina. Daar is helemaal niks over gezegd door sidefx.

[Reactie gewijzigd door AnonymousWP op 19 januari 2022 10:18]

Ervaar het proces zelf zou ik zeggen. Wijzig je wachtwoord maar eens op de site. Je krijgt het wachtwoord gewoon plain in de email. En dan op een linkje drukken om het te bevestigen (dus je kiest zelf niet je wachtwoord, die wordt voor je gemaakt).

En een captcha, om automatische onderschepping en verwerking van het mailbericht (dat mogelijk cleartext het internet over gaat) lastiger te maken.

[Reactie gewijzigd door The Zep Man op 19 januari 2022 10:10]

Dat zie je toch wel vaker?
Dat je dit tijdelijke wachtwoord gebruikt om in te loggen, vervolgens krijg je vaak de mogelijkheid om je wachtwoord zelf in te stellen.

behalve dat dat hier niet is. er is geen forcering om het tijdelijke wachtwoord te laten veranderen na login.

dus je nieuwe wachtwoord wordt plaintext verstuurd (via email) en er is geen mechanisme om te forceren dat je deze veranderd na de eerste login.

behalve dat dat hier niet is. er is geen forcering om het tijdelijke wachtwoord te laten veranderen na login.

dus je nieuwe wachtwoord wordt plaintext verstuurd (via email) en er is geen mechanisme om te forceren dat je deze veranderd na de eerste login.

Maar is dát dan geen eigen verantwoording ?
Leuk dat je dat doet, maar je bent er zelf bij ...

Omdat niet iedereen de kennis heeft die wij hebben en snapt dat je het dan moet wijzigen.
Zo simpel is het. Veel mensen zijn zich er niet bewust van.

Dan kan je wel zeggen "is dat geen eigen verantwoording" maar het feit is, helaas, dat als we ook geen complexiteit in wachtwoorden afdwongen het merendeel 1234567890 of wachtwoord01 zou gebruiken. ;-)

Er zijn nog system die dat doen, op zich niet heel erg als je dan direct je wachtwoord aanpast naar een zelf gekozen. Een groot deel van al het mailverkeer is tegenwoordig versleuteld.

[Reactie gewijzigd door GoBieN-Be op 19 januari 2022 10:07]

Een groot deel van al het mailverkeer is tegenwoordig versleuteld.

Is dat zo? Als gevolg van TLS-verbindingen tussen mailservers, of op een ander niveau?

TLS verbindingen tussen mailservers onderling en TLS verbindingen tussen clients en mailservers.

Voorbeeld van een willekeurige 365 tenant van een klant:
71,91% van de inkomende SMTP verbindingen is met TLS1.2 beveiligd.

"little confusion here, the new password is sent by email, but only activated if the user validates the change by clicking on the link in the email."

Bron

Er gaat wel meer fout. Na een "delete account" waarbij duidelijk staat "this cannot be undone" kan je het account gewoon weer gebruiken nadat je aangeeft dat je het wachtwoord bent vergeten. Je krijgt dan gewoon weer een activatielink waarna je in je oude account komt. Het account wordt dus niet verwijderd. Dit soort implementaties zijn gewoon prutswerk en zeer onveilig.

Ik betwijfel ook of er wel een proactieve melding is uitgegaan naar getroffen gebruikers. Ik heb in ieder geval niets gekregen en de melding op de website is ook niet heel erg opvallend.

[Reactie gewijzigd door Bor op 19 januari 2022 12:13]

Ja echt, absolute faalhazen en compleet aansprakelijk. Eerste keer al echt de meest simpele fouten maken en dan wederom today weten te presteren.

Ik raad iedereen aan zijn account daar te verwijderen. Vraag is of ze dan alleen een bool waarde op IsDeleted zetten ipv data weg halen.

Ik wil eigenlijk voor een site als OpenSubtitles juist helemaal geen moeilijk password. Ik moet dat nl op een ingewikkelde manier invoeren in mijn Kodi subtitles plugin... Het wachtwoord dat ze buit hadden gemaakt was mijn standaard makkelijke wachtwoord voor dat soort sites. Kun je verder helemaal niets mee.
Voor de meeste sites waar ik dit gebruikte heb ik nu wel een ingewikkeld wachtwoord laten genereren door LastPass, maar met dat wachtwoord kun je niets, hooguit een flauwe post op een onbelangrijk forum doen waardoor ze mij bannen. Het is ook al lang bekend bij de hekkerds en andere prutsers, die vage pogingen doen om mij te chanteren. Maar goed, dat soort dingen trap ik natuurlijk niet in.

ja, precies. Ik snap überhaupt niet waarom een login nodig zou zijn voor dit soort sites. Dus een weggooi email adres met random wachtwoord en geen echte persoonsgegevens.

Omdat de hosting anders te duur wordt. Nu konden ze nog een klein beetje reclame inkomsten vergaren op de site zelf.

Want je hebt accounts (met veelal nep gegevens) nodig om reclame inkomsten te vergaren? Die snap ik niet. Het lijkt me juist dat je kosten hoger zijn als je persoonsdata verwerkt en behoort te beveiligen. Users tracken voor reclame kan prima zonder accounts.

Dmv account forceer je mensen naar de site. Als er geen account nodig was, zouden mensen die Kodi en de OpenSubtitles plugin gebruiken nooit op de site komen.

Ik heb Kodi en de OpenSubtitles plug-in. Maar dat is voor mij geen reden om naar de site te gaan. Integendeel: voordat ik de plug-in ontdekte op Kodi zat ik vaker op de site om de ondertiteling te downloaden van wat ik wilde kijken, nu gebeurt dat "automatisch" dankzij de plug-in

Ik denk dat je, om een login aan te maken, akkoord moet gaan met de voorwaarden. Een "Intelectual Police" officer zou dan, om te 'infiltreren', akkoord moeten gaan met de voorwaarden waarin staat dat hij geen stoute dingen mag doen en dat hij akkoord gaat dat Opensubtitles geen blaam treft.

Dat jij een eenvoudig wachtwoord wilt voor een site, is aan jou. Dan kan een site er best voor kiezen om minimale(re) eisen te stellen aan waar een wachtwoord aan moet voldoen.

Dit staat los dat een site zijn eigen infrastructuur en techniek op orde moet hebben. Dat laatste is een probleem geweest met MD5.

Klopt, maar ik klaag ook niet. Alleen ben ik nu wel bezig met een inhaalslag om zwake wachtwoorden uit te bannen. Gelukkig kan mijn passwordmanager mij daarbij helpen.
En inderdaad, het is behoorlijk dom van ze om de wachtwoorden niet encrypted op te slaan.

Ik benader websites als OpenSubtitles.org als een soort amateur hobby website en daar laat ik sowieso zo weinig mogelijk info achter. Ik heb een apart webmail accountje voor dit soort zaken. Het kan me weinig schelen wat daarmee gebeurd. Uiteraard moet je voor iedere website een uniek WW hebben en een offline password manager gebruiken.

Herkenbaar argument. Ik heb precies hetzelfde voor OpenSubtitles. Dat wachtwoord moet zo makkelijk mogelijk zijn want anders is inloggen een drama. En het is nu niet zo dat die account heel belangrijk voor me is. Het is aangemaakt met een spam-emailaccount, juist omdat ik ze niet vertrouw met mijn persoonlijke gegevens.

Weer eentje voor de lijst. MD5 en script-injectie, dat klinkt als een oude site van begin 2000's, chapeau De subtitles waren net iets te open.

[Reactie gewijzigd door Basszje op 19 januari 2022 09:59]

Dat geven ze ook toe in hun blogpost (praat het overigens niet goed):

The site was created in 2006 with little knowledge of security, so passwords were stored in md5() hashes without salt

Wat anno 2022 een erg slecht excuus is. Het betekent namelijk ook dat ze sinds 2006 niets noemenswaardigs aan security hebben gedaan. Dit had al lang opgelost kunnen en moeten worden.

met welk geld? dit is een uit de klauwe gelopen passieproject, niet een professioneel bedrijf. ze moeten het doen met wat advertentieinkomsten, en donaties.

[Reactie gewijzigd door t link op 19 januari 2022 15:25]

Ook in het geval van een passieproject lijkt het mij zaak de boel goed te beveiligen. Wat we nu weten van de hack lijkt op nalatigheid. Dat kan uiteindelijk ook voor de 'gepassioneerde' aanbieder consequenties hebben.

ik ontken ook niet dat het niet zaak is de boel goed te beveiligen, ik vraag naar een realistische oplossing voor mensen op een klein budget.

Je kunt tegenwoordig je server of host beveiligen tegen SQL injectie. Ik heb websites van klanten jarenlang goed weten te laten draaien door bepaalde dingen of handelingen gewoon onmogelijk te maken. Echter als je in de logs kijkt zie je echt tientallen pogingen per dag, alles geautomatiseerd, dat wel.

Absoluut geen aanrader, maar het had wellicht gescheeld als de server ook gewoon bijgewerkt was en o.a Modsecurity draaide met een "Panic" modus ofzo.

Wel heeft hij toegang gekregen tot accounts, met name die met korte of slechte wachtwoorden, omdat die makkelijk te ontsleutelen zijn

Begrijp ik hier nu goed uit dat alleen accounts met een kort slecht wachtwoord bekend zijn en dat een account waarbij een complex wachtwoord is gebruikt niet ontsleuteld zijn en dat diegene niet bang hoef te zijn dat zijn wachtwoord bekend is?

Met MD5 is dat maximaal minutenwerk. Ongeachte de sterkte van je wachtwoord: met MD5 ben je het haasje en moet je een wachtwoord aanpassen.

OK...thanks

MD5 kan je gewoon vanuit huis "kraken" en dat gaat supersnel als je een flinke GPU hebt. Ook kan je op internet met een simpele copy paste van een MD5 wachtwoord, vaak het resultaat al vinden omdat het al eerder gekraakt is.

MD5 wachtwoorden in bezit hebben zijn relatief waardevol, omdat je hier een goede password list mee samen kunt stellen voor een bruteforce elders. Vroeger heb ik ook dingen staan kraken, toen was het nog relatief onschuldig om 1 wachtwoord voor werkelijk alles te hebben.

In het artikel staat dat gebruikers door de open subtitles site zijn geïnformeerd. Dit is niet geheel juist, ik ben niet door hen geïnformeerd terwijl ik wel van haveibeenpowned een melding heb ontvangen over deze breach.

Niemand die ik ken met een account heeft een melding ontvangen. Ik vermoed dat dit helemaal niet is gebeurd.

Nope niks gehoord, dikke onzin.

Wat ik wel kwalijk vind is dat de hack plaats heeft gevonden in augustus 2021 maar dat ze er nu pas mee naar buiten komen nadat de data dus gelekt is.

Wat ik wel kwalijk vind is dat de hack plaats heeft gevonden in augustus 2021 maar dat ze er nu pas mee naar buiten komen nadat de data dus gelekt is.

Misschien wisten ze er niets vanaf, totdat ze die 'dwangsom' opgelegd kregen.

Dit hebben ze zelf op hun forum gepost.

In August 2021 we received message on Telegram from a hacker, who showed us proof that he could gain access to the user table of opensubtitles.org, and downloaded a SQL dump from it.

Bedankt voor de aanvulling. I stand corrected :-P

Lekker dit. Ik heb geen bericht gehad. Uiteraard na dit Tweakersbericht direct mijn wachtwoord veranderd.

Toch handig, daags Tweakers checken 😉

Volgens mij hebben ze niemand direct benaderd. Ik kreeg melding omdat ik me ingeschreven heb bij haveibeenpwned.

Naast het wijzigen van het wachtwoord voor OpenSubtitles.org, is het dan dus ook verstandig het wachtwoord te wijzigen voor OpenSubtitles.com, mits je daar toegang toe hebt!