Amsterdams festival lekt wachtwoorden en persoonsgegevens van 110.000 bezoekers

De wachtwoorden en persoonsgegevens van bijna 110.000 bezoekers van het Amsterdamse festival DGTL waren eenvoudig in te zien. De inloggegevens van een oude database stonden online en de gegevens waren onvoldoende versleuteld.

Het gaat om een database met informatie van bezoekers die tussen 2015 en 2018 het technofestival bezochten. Een anonieme hacker zegt tegen RTL Nieuws dat hij in de code van de site de inloggegevens vond voor een database. Hierin vond hij de gegevens van 130.000 DGTL-bezoekers. Het gaat om onder meer naam, geslacht, leeftijd, e-mailadressen en woonadressen. Ook stonden er 'tienduizenden' 06-nummers in de database.

Daarnaast vond de hacker 109.360 wachtwoorden. Deze waren versleuteld, maar volgens RTL Nieuws werd hierbij een 'versleuteling gebruikt die al in 2008 als 'kapot en ongeschikt voor verder gebruik' werd bestempeld'. De versleuteling van de wachtwoorden is daarom 'veelal binnen enkele minuten' te kraken. Naast DGTL, zijn er ook ruim 100.000 e-mailadressen van Pleinvrees-bezoekers gelekt. De hacker kon ook de DGTL-website aanpassen en eigen nieuwsberichten toevoegen.

Hoewel de database niet meer in gebruik was, is de data volgens Jasper Goossen, ceo bij festivalorganisator Apenkooi Events, 'stom genoeg online blijven staan'. De Nederlandse hacker stuitte op het lek toen hij de digitale rij wilde omzeilen bij het kopen van kaartjes voor DGTL. Hij kwam daarbij de inloggegevens van de database tegen en kreeg zo toegang tot privacygevoelige data van 130.000 mensen. Naar verluidt meldde de hacker het lek in de zomer al bij DGTL en de siteontwikkelaar. Omdat het lek na enkele maanden nog steeds niet was gedicht, zocht hij de media op.

Momenteel doet DGTL onderzoek naar het voorval en heeft de organisatie melding gedaan bij de Autoriteit Persoonsgegevens. Daarnaast is er een werknemer aangenomen met kennis van privacy om dit soort incidenten in de toekomst te voorkomen. Bezoekers zijn nog niet geïnformeerd over het lek, maar Goossen stelt dat de organisatie wel van plan is gedupeerde bezoekers op de hoogte te stellen.

Reacties (94)

[RobinR_]

Bezoekers zijn nog niet geïnformeerd over het lek

Ik heb wel al een mail gekregen met het volgende:

Dear reader,

We are writing to you because of an incident involving access to information associated with online purchases made on our website www.dgtl.nl between 2015-2018.

Although we haven’t received any reports of misuse of your information, we are providing notice to you and other potentially affected customers about the incident.

The information in question has been taken offline and the data breach is fixed. Yet, we advise to change your password used on www.dgtl.nl and also on other platforms where you’ve may used this password. As requested by the GDPR, we reported this breach to The Dutch Data Protection Authority.

Furthermore, we have taken strong measures together with our hosting partner to prevent this from ever happening again.

If you have any questions regarding this matter, please reach out to [e-mail].

[Floort]

As requested by the GDPR, we reported this breach to The Dutch Data Protection Authority.

Ter informatie: dat zou betekenen dat ze het binnen 72 uur nadat ze op de hoogte zijn gesteld hebben gemeld en niet vlak nadat ze erachter zijn gekomen dat het de pers ging halen. Dat verschil is belangrijk omdat het ene eenvoudig voldoen is aan een wettelijke verplichting ("as requested"? Ha!) en het andere wel heel erg lijkt op een poging om het stil te houden totdat je er niet meer onderuit kan komen.

[knakworst]

As requested zie ik als steenkolen Engels. Ik denk dat ze bedoelen, as required by.

Ik ben wel heel benieuwd waarom ze in eerste instantie geen actie ondernamen. Inactief email adres?

[Floort]

Volgens RTLNieuws:

Hij meldde het lek afgelopen zomer bij zowel DGTL als de ontwikkelaar van de site, maar die wezen naar elkaar, stelt hij. Toen het lek na een paar maanden nog steeds niet was gedicht, besloot hij om naar de media te stappen.

Dat klinkt alsof in ieder geval de melder bewijs heeft van een reactie van DGTL waaruit blijkt dat ze ervan op de hoogte zijn.

[Gizz]

Ik ook, vanochtend om 10:30 uur.

Maar als ik het goed begrijp weet Apenkooi dit dus al maanden, maar worden we nu pas geïnformeerd? Dat vind ik ergens een nog grotere WTF dan het datalek zelf. Dat die gegevens online stonden is een domme fout, maar dat je iets al maanden weet en je klanten niet informeert lijkt me bewust beleid

[Reactie gewijzigd door Gizz op 23 juli 2024 04:52]

[Blokker_1999]

Of dat bewust beleid is kan je niets over zeggen. Dan moet je weten wat er na de melding met die informatie gebeurd is. Is dit op een helpdesk terecht gekomen en heeft de persoon daar de melding gewoon naar /dev/null gestuurd dan heeft die persoon een grote fout gemaakt, maar kan je de organisatie zeker niet beschuldigen van een slecht beleid in dat opzicht.

[Vihaio]

Uit het artikel van RTL blijkt dat de directeur van het bedrijf er na de melding vanaf wist.

Goossen stelt dat hij toentertijd de database heeft laten verwijderen en melding heeft gedaan bij de Autoriteit Persoonsgegevens. De bezoekers zijn niet geïnformeerd omdat dit volgens DGTL een 'te zwaar' middel zou zijn. De database bleek later niet daadwerkelijk te zijn verwijderd, omdat er nog kopieën te vinden waren.

"Natuurlijk zijn we eindverantwoordelijk voor de data van onze bezoekers, maar in de jaren waar we het over hebben hadden wij geen mensen met deze technische kennis in huis en besteedden wij dit uit aan externe partijen. Daar moeten we als marketeers ook op vertrouwen."

[GekkePrutser]

Hij is toch directeur? Dan moet hij zijn verantwoordelijkheid ook nemen. Het afdoen als "wij zijn maar marketeers, hier hebben we niks mee te maken want het is uitbesteed", doet me afvragen of ze ook zo hun handen afhouden als er wat ernstigs gebeurt op het evenement zelf. Ik neem aan dat ze ook geen kennis hebben of tenten- of steigerbouw goed gebeurt. Maar toch ben je verantwoordelijk als zoiets omvalt op het terrein.

Hij had bijvoorbeeld zelf contact kunnen hebben met de hacker/melder om het probleem beter te doorgronden. Die had het ongetwijfeld duidelijk kunnen uitleggen zoals het ook in het artikel staat, dan was ook duidelijk geweest of het echt opgelost was.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 04:52]

[amx]

Aangaande het: "wij zijn maar marketeers": ja het lokt vanuit de ICT kant felle reacties uit.
Advocaat van de duivel: als niet-ICT'er is het verschil tussen ransomware en iemand die je vertelt dat je kosten moet maken om iets te laten beveiligen kiezen tussen twee kwaden: de directe baten zijn namelijk niet te kwantificeren en je voelt je gedwongen om met geld over de brug te komen.

Wat betreft de laatste opmerking: hij had ook zelf contact kunnen hebben met de hacker: die spreekt een compleet andere taal dan een directeur.

[Marrtijn]

Hij is toch directeur? Dan moet hij zijn verantwoordelijkheid ook nemen.

Hallo, het is 2022. Dat doen doen directeuren niet meer.

[Floort]

Interessant in dit kader is de boete van 475.000,- euro voor Booking.com voor het 22 dagen te laat melden van een datalek. Booking heeft iets dergelijks beargumenteerd (pag 14/15 van het rapport) en is daar niet mee weggekomen.

[mare]

Maar als ze je maanden eerder op de hoogte hadden gesteld, dan hadden ze misschien wel negatieve gevolgen ondervonden en we hebben net de corona crisis achter de rug.... of ander soort geneuzel van kortzichtige "ondernemers" met nul verstand van digitaal. Zeker een WTF die beboet moet worden als nalatigheid zodat andere bedrijven ervan kunnen leren.

[SunnieNL]

Mensen niet op de hoogte stellen is één..
De niet meer in gebruikzijnde database laten staan is een ander.. Dat is misschien nog wel erger. Als die database niet in gebruik is, waarom is die dan op zijn minst niet verwijderd na de melding?

[StefanJanssen]

Bewust beleid, of gebrek aan communicatie binnen de organisatie (wat mij waarschijnlijker lijkt).

Stel dit komt bij een service medewerker terecht die dit wil doorgeven maar omdat de baas even een weekje niet beschikbaar is compleet is vergeten door te geven.

[kodak]

Stellen dat het datalek opgelost is, dan heb je als bedrijf of niet begrepen wat een lek is, of je wil het mooier laten lijken dan het is.

Wat mij betreft is een datalek pas opgelost als je zeker weet dat er geen data verder lekt. En aangezien het bedrijf en de hoster dat verder lekken niet kunnen uitsluiten, hebben ze alleen de oorzaak opgelost.

Ook staat er opvallend niets over hoe lang het lek bestond en dat het ze kennelijk maanden lang nam het te weten lieten bestaan.
Ook lees ik niets hoe ze verder verantwoordelijkheid nemen voor de gevolgen voor hun klanten.

Het komt op mij over dat deze ondernemers weinig op hebben met hun ik klanten en meer bezig zijn om er vooral zelf zo min mogelijk problemen mee te hebben door het zo te brengen.

Het lijkt tijd te zijn dat er ook minimale eisen over inhoud van informeren komen. Als wetsovertreders zelf beslissen wat slachtoffers van hun moeten weten en problemen via hun kunnen oplossen lijkt namelijk niet in het belang van de slachtoffers te gebeuren. Eisen als duidelijk zijn dat je controle had moeten hebben maar niet meer zeker hebt. Duidelijk zijn waar slachtoffers onafhankelijk melding kunnen doen bij de toezichthouder. Duidelijk zijn welke fouten je hebt gemaakt en hoe lang dat kon. Duidelijk zijn wat de gevolgen nog kunnen zijn en wat het bedrijf daar voor verantwoordelijkheid neemt. Het informeren is te vrijblijvend en in het voordeel van de wetsovertreders.

[Reactie gewijzigd door kodak op 23 juli 2024 04:52]

[Tomatoman]

Jij impliceert dat het hele onderzoek en de verdere afhandeling van het datalek geregeld en gerapporteerd zou moeten zijn in dat eerste mailbericht. Dat is wel wat veel gevraagd. Ze informeren nu schoorvoetend de getroffen personen en geven aan dat het lek is gedicht. Dat is de eerste noodzakelijke stap, niet het complete afhandelingstraject.

[kodak]

Ik vraag om voldoende verantwoordelijkheid die al te nemen is. Maar dat is kennelijk al teveel gevraagd.

In de bron staat dat de ondernemers er van wisten en klanten informeren een te zwaar middel vonden. Dat is, te zwaar voor zichzelf. Want hoe je het als ondernemer ook draait, je klanten opzettelijk zo min mogelijk vertellen dat je de wet met hun persoonlijke gegevens massaal hebt overtreden klinkt niet als je klanten en hun persoonlijke gegevens serieus nemen.

Het is duidelijk dat het lek niet alleen gaat om het verhelpen van een oorzaak. Er zijn duidelijke zorgen dat het lek al maanden geleden gemeld is. Er is al duidelijkheid dat het bedrijf geen controle over mogelijk gelekte gegevens heeft. Dat het bedrijf daarin verantwoordelijkheid heeft, ook na het wegnemen van de oorzaak. Het is duidelijk dat klanten niet alleen terecht hoeven bij de wetsovertreder.
Daar op in gaan is juist niet teveel gevraagd. Het onderzoek hoort geen excuus te zijn om nagenoeg niets te melden. Zelfs een belofte om meer informatie of hulp geeft men ook niet duidelijk. Vaag mag je als klant eens zelf contact gaan opnemen met een bedrijf dat de klanten en hun gegevens al niet zo serieus neemt.

[Reactie gewijzigd door kodak op 23 juli 2024 04:52]

[JumpStart]

Als een side-note: Het Engels laat nogal te wensen over, maar dat is niet geheel ongebruikelijk ...

"... where you've may used" = where you have may used -> Where you may have used
"As requested by the GDPR" -> As required by the GDPR

De General Data Protection Regulation is een regelgeving, die vraagt (verzoekt) niet, die vereist.

[CyBeRSPiN]

Waarom moet je volledige geboortedatum en telefoonnummer überhaupt weten als organisatie van een festival?
Weten of iemand boven de 18 is kan ik nog inkomen, dat is dan een ja/nee veld.

Moet echt afgelopen zijn met al die clubs die maar allerlei data van je vragen terwijl ze daar helemaal geen valide reden voor hebben. Ik vul daar altijd onzin is, maar velen zijn naïef en vullen alles naar waarheid in.

[Lisadr]

Veel ticket sites vragen om naam, geslacht, leeftijd, e-mailadres, woonadresse en mobiele nummer. Ondanks dat de kaarten digitaal zijn, is het verplicht om een adres door te geven.

Tijd dat hij zware boetes voor komen!
Eerste keer, aantal gelekte personen x 5 euro!
Tweede keer, aantal gelekte personen x 20 euro!
Derde keer, aantal gelekte personen keer 100 euro!

[TheVivaldi]

En dan een boete voor het festival als blijkt dat ze een ticket voor een 18+-festival aan een 13-jarige hebben verkocht omdat er geen geboortedatum bekend was? Want volgens de wet mag je geen 18+-tickets aan minderjarigen verkopen.

[Cycatrix]

Je kan toch "ben je 18+" tickbox implementeren. Tuurlijk, iemand kan die aanvinken terwijl hij minderjarig is. Maar iemand kan ook een geboortedatum invullen waardoor hij meerderjarig lijkt.

Als je een dertienjarige ziet rondwandelen kan je hem gewoon om ID vragen en hem eruit gooien. Of je nou liegt over je geboortedatum of omdat je de 18+ tickbox hebt aangevinkt.

[RoestVrijStaal]

Weten of iemand boven de 18 is kan ik nog inkomen, dat is dan een ja/nee veld.

IANAL, maar het zal me niet verbazen dat de wet ook verbiedt om tickets van 18+ festivals te verkopen aan <18-ers. Een datum veld is dan beter voor het "terugrekenen" dan een ja/nee veld.

Ik vul daar altijd onzin is, maar velen zijn naïef en vullen alles naar waarheid in.

Omgekeerd als de festival-beveiligers je ticket met identiteitsbewijs controleren en het komt niet overeen, hebben ze een goede reden om je eruit te zetten. Niet iedereen wil dat risico nemen en/of zo'n spanning ervaren tijdens het festival.

edit:
Typo

[Reactie gewijzigd door RoestVrijStaal op 23 juli 2024 04:52]

[Verwijderd]

Je kan toch prima om geboortedatum vragen, zelf je berekening doen in de backend, en dan een boolean opslaan? Beveiligers hebben helemaal niks te maken met wie jij als persoon bent, maar of je ticket geldig is. Als ze vermoeden dat je ondanks je geldige ticket toch te jong bent, kunnen ze ter plekke om je identiteitsbewijs vragen zoals dat ook gebeurt als je zonder reservering een club of bar in loopt.

[Zyppora]

Deze gegevens zullen waarschijnlijk dan weer vanwege andere wetgeving verplicht zijn, iets vergelijkbaars als KYC of zo. Plus dat het op die manier wat eenvoudiger is om mensen die zich in het verleden zwaar misdragen hebben te weren van toekomstige evenementen, ook niet volledig onwenselijk als je het mij vraagt.

Ik zeg niet dat ze het minimale vragen, maar ze zullen met 'CyBeRSPiN' als voor- en achternaam geen genoegen nemen

Dat ontslaat ze overigens niet van de verplichting die gegevens achter voldoende beveiliging te bewaren, en dat is hier gewoon overduidelijk niet gebeurd. En vervolgens ook nog eens proberen de zaak onder het tapijt te vegen? Daar mogen ze wat mij betreft best voor bloeden.

[Groningerkoek]

Dus:

- Een bedrijf beheert gegevens die ze allang niet meer hadden moeten hebben.
- Het bedrijf laat die gegevens zelfs online staan.
- Het bedrijf publiceert de inloggegevens open en bloot op internet.
- Het bedrijf laat die gegevens maandenlang vrij toegankelijk op internet staan na een melding.
- Het bedrijf gebruikt een versleuteling die zo antiek is dat je net zo goed plain text kunt gebruiken.

Ik geloof er niet meer in dat dit gaat veranderen op de huidige manier, we moeten de aanpak gaan veranderen. De overheid moet minimale eisen stellen en deze jaarlijks updaten en duidelijk communiceren en bij zware overtredingen zoals hier dienen er gewoon gevangenisstraffen te worden uitgedeeld, ik ben er wel klaar mee.

Ook ben ik er wel klaar mee dat iedereen maar naar iedereen kan wijzen. Ik ben Elektriciën en persoonlijk aansprakelijk als ik grove fouten maak die tegen de regelgeving in gaan. Waarom gaan we geen eisen stellen aan programmeurs? Kappen met "we doen wat de klant wil" daar komt een loodgieter of elektricien ook niet mee weg.

[Reactie gewijzigd door Groningerkoek op 23 juli 2024 04:52]

[TMDevil]

Het probleem is dat er nu geld boetes worden gegeven aan bedrijven, maar niemand echt verantwoordelijk is. Ik zou daarom zeggen, stel de CEO en eventuele managers persoonlijk verantwoordelijk. En niet alleen financieel, maar ook bijvoorbeeld celstraf.
Daardoor zal een CEO of manager wel 2x nadenken zodra een ontwikkelaar zegt dat het niet veilig is.

[Groningerkoek]

En dat bedoel ik, de huidige aanpak gaat het niet oplossen.

Bedrijven dienen naast het zorg dragen voor voorkoming overbodige opslag en goede veiligheid bijvoorbeeld ook procedures kunnen overleggen hoe er met een lek wordt omgegaan, hoe er met meldingen wordt omgegaan. Op websites dient een vast aanspreekpunt voor dit meldingen vermeldt te worden etc..

[Reactie gewijzigd door Groningerkoek op 23 juli 2024 04:52]

[Verwijderd]

MD5.

Met hedendaagse rekenkracht vrij makkelijk te bruteforcen. En vaak kan je een MD5 hash al in google smijten en direct het wachtwoord verkrijgen.

[Verwijderd]

Waarom gaan we geen eisen stellen aan programmeurs? Kappen met "we doen wat de klant wil" daar komt een loodgieter of elektricien ook niet mee weg.

Als programmeur bent ik het hier helemaal mee eens. Veel te veel prutsers in de industrie.

[Godson-2]

Hmmm, binnen enkele minuten te kraken? Dat zal MD5 of zoiets zijn? En dan enkelvoudig gehashed?

[Verwijderd]

Godson-2 schreef:

Hmmm, binnen enkele minuten te kraken? Dat zal MD5 of zoiets zijn? En dan enkelvoudig gehashed?

Om misverstanden te voorkomen: MD5 is niet zodanig "gekraakt" dat je uit een MD5-hashwaarde het oorspronkelijke wachtwoord (of een ander wachtwoord dat toevallig dezelfde hash oplevert, een "preimage collission" dus) kunt herleiden.

Het probleem is tweeledig:
1) De meeste mensen kiezen vaak gebruikte wachtwoorden (die eerder zijn gelekt, meestal van anderen), veel te korte-, of te raden wachtwoorden (denk aan iets dat je van iemand te weten kunt komen, zoals "9-sep-92");

2) Elke reguliere cryptografische hashfunctie, niet alleen MD5 maar ook SHA-3, is zeer snel op moderne hardware.

Omdat aanvallers weten dat webservers, in plaats van de wachtwoorden zelf, daar hashes -gemaakt met een snelle functie- van opslaan en later mogelijk lekken, kunnen die aanvallers vooraf en in relatief korte tijd een tabel maken met twee kolommen:
links eerdere gelekte wachtwoorden, zelf gegenereerde korte wachtwoorden (aaaaa, aaaab, aaaac etc.) en eventueel geraden wachtwoorden. Rechts plaatsen ze de door henzelf berekende hashwaarde voor elk van die wachtwoorden. Dit noemen we een rainbow table.

Voorbeeld:
"12345" 827ccb0eea8a706c4c34a16891f84e7b
"Geheim" d1c9a9d96ec1b245bd976930be6b9ab3

Een vinder van wachtwoordhashes in een database zoals van DGTL kan voor elke hash kijken of deze vóórkomt in de rechterkolom van zijn rainbow table (of zo'n tabel op internet). Dit zal niet voor elke hash het geval zijn, maar vaak geldt dit wel voor veel daarvan.

Voor elke gevonden hash ziet de aanvaller in de linkerkolom het bijbehorende wachtwoord, en omdat ook het e-mailadres gelekt is, kunnen daarmee credential stuffing aanvallen worden uitgevoerd (op andere websites dus).

Dit is niet kraken van cryptografische hashfuncties, maar m.i. grotendeels een gevolg van menselijke tekortkomingen en geen wachtwoordmanager (willen) gebruiken, dus geen lang random gegenereerd (uniek of weinig gebruikt) wachtwoord per account hebben.

Je kunt het aanvallers moeilijker maken door, in plaats van een snelle hashfunctie (nesten heeft nauwelijks zin), een bewust traag gemaakte functie zoals Argon2 in te zetten. Gebruikers zullen dan (soms of vaak) langer moeten wachten voordat hun wachtwoord wordt goedgekeurd en zij zijn ingelogd.

Maar daar betaalt ook de server-eigenaar (of huurder) een prijs voor, want ook op jouw server kost dat performance (dus Euro's) en je vergroot de kans op DoS aanvallen met grote impact.

Een salt (of een unieke salt per account) kan ook helpen, maar vaak niet genoeg omdat aanvallers daarmee snel een op die salt(s) aangepaste rainbow table kunnen maken.

De grootste fout van DGTL is m.i. dat persoonsgegevens toegankelijk waren, wachtwoord-afgeleiden zouden bijzaak moeten zijn.

[kaas-schaaf]

Over digests gesproken: op een beetje moderne gpu alle 1 tot 8 karakter md5 (md5crypt is iets moeilijker maar ook te doen) digests zonder salts te berekenen binnen een dag, tenzij niet de default maar meer rounds zijn toegepast maar ik acht de kans niet heel groot. Daar heb je geen rainbow table voor nodig (uiteraard is dat wel sneller). Met een beetje slim masken kom je ook nog wel tot de 10 karakters als je er tijd en moeite in wilt stoppen.

[Reactie gewijzigd door kaas-schaaf op 23 juli 2024 04:52]

[ajakkes_mob]

"Een salt (of een unieke salt per account) kan ook helpen, maar vaak niet genoeg omdat aanvallers daarmee snel een op die salt(s) aangepaste rainbow table kunnen maken"

Een unieke salt per account helpt heel veel tegen rainbow tables. Je moet dan namelijk voor ieder account een eigen rainbow table maken. Dit is nog wel te doen voor de 1% meest gebruikte wachtwoorden, maar wordt bij een beetje uniek wachtwoord al vervelend.

Voor 10000 accounts md5(md5(accountnaam)+'Welkom01') gaat vast wel wat opleveren. Met sha512('Welkom01') hoef je niet eens je best te doen.

[Verwijderd]

ajakkes_mob schreef onder meer:

Een unieke salt per account helpt heel veel tegen rainbow tables. Je moet dan namelijk voor ieder account een eigen rainbow table maken.

Je hebt absoluut gelijk dat dit aanvallers kan vertragen.

Echter, als aanvallers dit slim aanpakken, kunnen nog steeds wachtwoorden worden achterhaald, alleen van minder accounts.

Het fundamentele probleem van mensen die zwakke wachtwoorden zelf hergebruiken (en daardoor bijv. bijna 200.000 North Face accounts via credential stuffing gehacked kunnen worden), los je hier dus niet mee op.

Bovendien heb je hier niet n rainbow tables voor nodig. Sterker, het kan op de manier die @kaas-schaaf beschreef: geheel zonder rainbow table(s).

Als ik aanvaller was zou ik uitgaan van een dictionary met veelgebruikte wachtwoorden, gesorteerd van meest naar minst gebruikt.

Voor elk wachtwoord ww in die lijst, doorloop je de gekopiejatte database met, per record, salt + opgeslagen hash: je berekent de hash uit ww en salt en vergelijkt de berekende met de opgeslagen hash. Als de hashes identiek zijn weet je het wachtwoord van dit account (dan gooi je dit record uit de database) en zoek je verder.

Dit kan een time-limited aanval zijn, of je kunt stoppen na de wachtwoorden van n accounts te hebben gevonden. In elk geval iedereen met "12345", "Geheim" of "Welkom01" haal je er zo wel uit, en heel veel tijd zal dat niet kosten.

ajakkes_mob schreef ook:

Dit is nog wel te doen voor de 1% meest gebruikte wachtwoorden, maar wordt bij een beetje uniek wachtwoord al vervelend.

Eens, het grootste probleem zijn mensen die totaal waardeloze wachtwoorden gebruiken, maar ik vermoed dat veel meer dan 1% dat doet.

Ik vind het vooral over the top om met zware maatregelen (met allerlei bijwerkingen) te proberen die mensen tegen zichzelf te beschermen en vervolgens te roepen dat het de schuld van een servereigenaar is als, door die sukkels, een deel van de wachtwoordhashes toch "te reversen" blijkt.

Advocaat van de duivel spelend: MD5 zou goed genoeg moeten zijn. Als je een lang genoeg random wachtwoord (of vermoedelijk unieke wachtzin) kiest, is jouw risico waarschijnlijk zelfs klein als je datzelfde wachtwoord voor meerdere accounts gebruikt - mits geen van de betrokken servers gehacked is en/of jouw wachtwoord als plain text opslaat.

Nb. hergebruik raad ik natuurlijk af, want dat laatste weet je nooit zeker.

[n9iels]

MD5 of SHA1 waarschijnlijk dan, maar het is schandalig dat dat nooit is gemigreerd naar iets beter. Oude legacy systemen heb je altijd en roeptoeteren daarover vanaf de zijlijn is erg makkelijk. Maar dit had 10 jaar terug al gefixt moeten zijn.

[DJMaze]

Misschien was het al gefixt met rot13($oude_md5_hash)...

[CH4OS]

Zou zonde zijn om het op zo'n manier op te lossen. PHP bijvoorbeeld kent namelijk een heel tof werkend password hashing systeem tegenwoordig met password_hash(), password_verify() en password_needs_rehash().

Middels deze functies en het gebruik van de PASSWORD_DEFAULT constante, worden passwords altijd 'up to date' gehouden wanneer PHP een nieuwe hashing algoritme als standaard gaat gebruiken en een gebruiker met zijn credentials inlogt.
Bij een goede implementatie hoef je dus voor PHP (in theorie) enkel PHP te updaten en worden passwords wanneer nodig automatisch rehashed naar de nieuwe hasning standaard.

[Reactie gewijzigd door CH4OS op 23 juli 2024 04:52]

[Jermaine]

Het betreft MD5-versleuteling, ja.

[Blokker_1999]

Hashing, geen versleuteling. Dat laatste wil zeggen dat je met de juiste sleutel het origineel terug kunt halen.

[SAVAGE3]

Het ging inderdaad om wachtwoorden die hashed zijn met MD5.

[Hans C]

De Nederlandse hacker stuitte op het lek toen hij de digitale rij wilde omzeilen bij het kopen van kaartjes voor DGTL.

Ook lekker fris motief om op de site rond te struinen.

[Jermaine]

Ik vraag me af of, als je de digitale wachtrij wilt omzeilen, het dan helpt om domein.tld/.git/ te benaderen

[cyclone]

Neuh maar als je toch aan het enumaraten bent vindt je vaak zaken waar je niet perse naar op zoek bent maar wel de moeite waard zijn om even te onderzoeken.
Zie hier, waarom de wachtrij omzeilen als je gewoon de Database binnen kunt wandelen en zonder te betalen je toegangskaarten in de DB kunt knallen.

Er zijn meer wegen die naar Rome leiden, als het ene niet lukt dan het andere maar.

Try ... HARDER :-)

[Jago2]

Het lijkt mij dat dit eerder hobby / leuk is dan dat deze persoon verwacht er zoveel tijd mee te besparen (integendeel)

Bovendien is het gevonden (belangrijke) probleem netjes gemeld. Bizar dat deze organisatie blijkbaar hoopt dat het in de doofpot kan verdwijnen.

[Hans C]

Misschien niet meteen tijd besparen, maar er wel zeker van willen zijn dat bij uitverkoop jij tenminste een kaartje hebt?

[Bender]

Een developer die handmatig even rondkijkt, wint het alsnog niet van de de developers die daar bots voor gemaakt hebben.
(kijk maar naar Ticketswap, verkopers met 5000+ verkopen..)

[Bender]

Het is meer een gezonde interesse als je zelf developer bent, ik doe dit soort dingen ook vaak.

[HansMij]

Daarom gebruik ik op mijn site wel eens honeypots. Zoek je bijvoorbeeld naar wordpress-logins (welke ik niet gebruik), dan ben je wat mij betreft met onfrisse zaken bezig en blokkeert fail2ban automatisch jouw IP.

[Bender]

Dit heeft werkelijk niks te maken met logins zoeken...

[Tommie Poehee]

Tja er staat hacker, niet Ethische hacker

[Verwijderd]

En daarom moet je zoveel mogelijk fake informatie invullen waar mogelijk, en waar niet mogelijk is zoeken voor alternatieve evenementen in dit geval, maar ook met andere delen van het internet is het belangrijk om software, sites en apps te gebruiken waar je fake informatie voldoende is.

[Webdoc]

De vraag is natuurlijk waarom een festival al die gegevens denkt nodig te hebben...? Het is toch helemaal niet belangrijk voor ze? En dit geldt overigens voor more less 90% van alle online tokos die te pas en te onpas veel te veel dingen van je willen weten die niets met hun business te maken hebben. Een online winkel bijvoorbeeld heeft niets meer nodig dan een bewijs dat je het recht hebt om het gekozen betaalmiddel te gebruiken, 1 contact-gegeven en eventueel een adres (al dan niet een anoniem nummer dat enkel bij een koerier aan een fysiek adres kan worden gekoppeld). De rest is letterlijk none of their business.

[CAPSLOCK2000]

1 contact-gegeven en eventueel een adres (al dan niet een anoniem nummer dat enkel bij een koerier aan een fysiek adres kan worden gekoppeld).

Een paar jaar geleden bestond dit. Het was geweldig.
Ik liet mijn pakjes opsturen naar het adres een bedrijf met mijn klantnummer als ontvanger.
Dat bedrijf had kluisjes geplaatst op de parkeerplek van mijn werkgever.
Twee keer per dag reden ze met een busje rond om de ontvangen pakketjes in de kluisjes te doen.
Na mijn werk kon ik daar mijn pakketje oppikken door het kluisje te openen met een pincode die ze me stuurde.

Ik deed dat niet om anoniem te zijn maar het was wel een leuke bijkomstigheid. Alleen het pakketbedrijf wist mijn echte naam en ik had er over kunnen liegen. Mijn adres hadden ze niet eens (volgens mij zijn ze dat later wel gaan vragen, maar niet op het moment dat ik klant werd). Ik snap dat volledige anonimteit een deur openzet voor criminaliteit maar dat is verder niet nodig om dit concept te laten werken.

Echt anoniem is het natuurlijk ook niet als ik iets online bestel en via de bank betaal, maar dat was het punt dus niet. De leverancier hoeft die gegevens niet te bewaren.

Eigenlijk hoeft een webshop maar 2 dingen te weten:

1. Besteling nummer X is betaald,
2. om 3 uur komt de postbode pakket X afhalen.

Om 3:01 kun je die informatie weer weggooien.

[dikkechaap]

Helaas kan je die info niet om 3:01 weggooien. Als een klant klaagt dat hij een pakket nooit heeft ontvangen wil je kunnen aantonen dat het verstuurd is. Daarnaast heb je nog retouren, garantie etc. etc.

[CAPSLOCK2000]

Helaas kan je die info niet om 3:01 weggooien. Als een klant klaagt dat hij een pakket nooit heeft ontvangen wil je kunnen aantonen dat het verstuurd is. Daarnaast heb je nog retouren, garantie etc. etc.

Ik geef toe dat het niet helemaal zo simpel is, maar voor de problemen die je noemt zijn andere oplossingen te bedenken.

Als ik bij de mediamarkt een TV koop hoef ik mijn naam en adres niet op te geven. Als ik ruilen of garantie wil hoef ik alleen maar de aankoopbon te laten zien. Zo'n bon zit nu ook al bij vrijwel ieder pakketje dat ik bestel.

Bezorgproblemen zijn lastig, maar wat helpt het als de winkel zelf het adres weet? Uiteindelijk zijn we afhankelijk van de postbode/courier. Die zegt dat een pakket wel of niet is bezorgd en "bewijst" dat met een handtekening.

In bepaalde gevallen is het ook nog mogelijk om opnieuw naar bepaalde gegevens te vragen. Bv om opnieuw een bezorgadres in te vullen op het formulier van de courier.

Misschien is het specifieke voorbeel dat ik gaf niet helemaal uitvoerbaar maar het gaat om de insteek: zoek naar manieren om je doel te bereiken met zo min mogelijk data. Hoe minder je hebt, hoe minder er mis kan gaan.

[david-v]

stom genoeg online blijven staan

Understatement van het jaar. Graag boete voor dit soort bedrijven die nog zo over avg data denken.

[logix147]

Dat men zelfs geen budget heeft om een UTP kabel uit een database te halen of de VM gewoon uit te zetten… tja dat is dieptriest.

[HenkEisDS]

Ook een zaak aanspannen tegen de bestuurders gaarne.

[Vinny_93]

Bezoekers zijn nog niet geïnformeerd over het lek, maar Goossen stelt dat de organisatie wel van plan is gedupeerde bezoekers op de hoogte te stellen.

Ik has anders on 10:26 vandaag keurig een mailtje van DGTL. Dus dit is ofwel oude info, ofwel onjuist.

[JoQeZ]

Oude info. Tweakers heeft van het bericht van RTL nieuws afgekeken, toen had DGLT inderdaad nog niemand benaderd (en was de database nog steeds publiekelijk bereikbaar)

[Dograver]

Naar verluidt meldde de hacker het lek in de zomer al bij DGTL en de siteontwikkelaar. Omdat het lek na enkele maanden nog steeds niet was gedicht, zocht hij de media op.

Dan ben je toch als eindverantwoordelijke toch ook lekker aan het struisvogelen hoor.
Je laat dus een database overeind die je niet langer gebruikt. Je wordt gehacked om dan vervolgens nog geen actie te ondernemen. Sorry, maar dan verdien je deze schandpaal gewoon voor de volle 100%

[david-v]

Schandpaal én boete!

Daarnaast is er een werknemer aangenomen met kennis van privacy om dit soort incidenten in de toekomst te voorkomen

Misschien ook uitbesteden aan een partij die niet alleen privacy kennis heeft, maar ook technische en juridische kennis. Met één werknemer ga je het echt niet voorkomen in de toekomst.

[kodak]

de data volgens Jasper Goossen, ceo bij festivalorganisator Apenkooi Events, 'stom genoeg online blijven staan'

Is dit het stom genoeg omdat ze er nu zelf last van hebben, of stom genoeg omdat het ze voor het publiek werd de persoonlijke gegevens van anderen echt probeerde te beschermen?