Bank zegt Ticketmaster begin april al over fraude te hebben geïnformeerd

De Britse bank Monzo waarschuwde Ticketmaster al begin april over opvallende transacties die wellicht wezen op een datalek. De bank claimt na onderzoek destijds al overtuigd geweest te zijn dat er sprake was van een datalek.

Monzo kreeg op vrijdag 6 april vijftig meldingen van frauduleuze transacties met hun bankkaart. Na analyse bleek de meerderheid van die kaarten tussen december 2017 en april 2018 bij Ticketmaster gebruikt te zijn. De bank paste zijn systemen aan om vergelijkbare fraude te herkennen en kaarten direct te blokkeren. Ook nam Monzo contact op met de autoriteiten en andere banken, die echter geen vergelijkbare gevallen hadden geconstateerd.

In de dagen erna kwam Monzo wel meer gevallen van fraude tegen waarbij kaarten bij Ticketmaster gebruikt waren en op 12 april ging het beveiligingsteam van de bank op bezoek bij Ticketmaster om hun vergaarde informatie te delen. Het ticketbedrijf zei toen de zaak te onderzoeken.

Bij een volgende fraudepoging ontdekte Monzo dat de criminelen een verkeerde vervaldatum invoerden. De klant had diezelfde datum eerder per ongeluk bij Ticketmaster ingevoerd. De bank claimt er toen van overtuigd te zijn geworden dat er een datalek bij Ticketmaster was. Dat bedrijf vertelde Monzo echter op 19 april dat intern onderzoek geen onregelmatigheden aan het licht had gebracht.

Donderdag maakte Ticketmaster UK bekend dat een deel van zijn internationale klanten die tussen september 2017 en 23 juni 2018 kaarten hebben gekocht of dat hebben geprobeerd, slachtoffer waren geworden van een datalek.

Reacties (59)

[joepsel]

Hier nog uitgebreide achtergrondinformatie over dit lek, door Kevin Beaumont:

https://doublepulsar.com/...he-coal-mine-5c7410e8565b

[Kaasdipje]

In hoeverre kan TicketMaster dan voor nalatigdheid gestrafd worden? En verantwoordlijk worden gesteld voor de schade? Als ze al zijn gewaarschuwd lijkt me toch dat dit zeer serieus genomen had moeten worden.

[Bender]

Wie zegt dat het niet serieus genomen werd?

TM zelf zag geen vreemde dingen in hun systemen. Dergelijke transacties zullen ze ook niet zien.

Het probleem lag bij een derde partij, daar hebben zij geen inzage toe.

[ouweklimgeit]

Onjuist. De CEO van Inbenta heeft aangegeven dat TM zelf de javascript code heeft toegevoegd aan de betaalpagina en dat dit zonder overleg gebeurd is. https://www.inbenta.com/e...ticketmaster-data-breach/

[Trekfolie]

Het blijkt dus dat ze zomaar een javascript op een betaalpagina hebben gezet waar Inbeta, als ze het hadden geweten, TM had van willen weerhouden.

Dus zeggen dat het probleem bij een derde partij en TM daar geen inzage in had is, met alle respect, iets te kort door de bocht.

[ronaldmathies]

Ze hebben het toegevoegd aan de betaalpagina, het script was wel door Inbeta gebouwd op verzoek van TM, ze gingen er alleen vanuit dat het niet op de betaalpagina gebruikt zou worden. Dus hier haal ik wel een paar punten uit:

1. Had Inbeta TM moeten vertellen dat het script niet gebruikt moest worden op de betaalpagina? (waarom de klant als actiehouder om dit te vragen / vertellen doen als het je eigen product is)
2. Had Inbeta het script niet zo moeten maken dat het overal veilig te gebruiken was?
3. Had Inbeta uberhaupt een dergelijk script moeten bouwen (wat door geen enkele andere klant gebruikt wordt)? Want onderhoud zal er dan haast niet op gepleegt worden met mogelijk lekken op andere plekken tot gevolg.

Dus helemaal niet verantwoordelijk zou ik Inbeta niet noemen.. Maar meer dat de verantwoordelijkheid bij beide partijen ligt.

[Trekfolie]

Ik ben het volledig met je eens. Met iets te kort door de bocht bedoel ik ook niet dat er geen schuld ligt bij Inbeta.

Overigens is TicketMaster op 10 mei op Twitter gewaarschuwd dat er informatie naar een, door externe persoon beheerde website, wordt doorgestuurd.

[Reactie gewijzigd door Trekfolie op 22 juli 2024 15:55]

[kakanox]

Overigens is TicketMaster op 10 mei op Twitter gewaarschuwd dat er informatie naar een, door externe persoon beheerde website, wordt doorgestuurd.

Ik lees daar ook dat e.e.a. op 10 Mei opgelost is. Is dat dan niet waar?
Buiten dat ze al fout zitten i.v.m. het niet melden van een datalek, natuurlijk.

[BarôZZa]

Het is een grote fout van TM geweest om überhaupt externe scripts te laden op de betaalpagina omdat je daar geen controle over hebt. Helaas zie je dat dit ook bij webshops en dergelijke nog vaak voorkomt. Blind vertrouwen in andere services en klakkeloos tig javascripts inladen op pagina's die veilig zouden moeten zijn.

[bArAbAtsbB]

ze hebben dus niet ver genoeg hun eigen processen doorgekeken...ze moeten niet stoppen bij hun eigen voordeur..maar het hele proces bekijken wat de klanten doorlopen!

[Bender]

Je ziet ze al de bank bellen en vragen of ze even toegang mogen tot de code van de bank om daar de code te bekijken? :-P

[bArAbAtsbB]

de bank meldde aan TM dat er een lek was...het lek zat dus niet bij de bank!

[Bender]

Je begrijpt het punt niet....

[bArAbAtsbB]

ik begrijp je punt heel goed...maar het is te kort door de bocht...ze maken gebruik van een keten dan houdt het onderzoek niet op bij hun voordeur!

[Bender]

Wie zegt dat dat gebeurt is dan?

[Bender]

Nee, je trekt het hele punt totaal uit zijn verband zonder op de inhoud in te gaan.

[Belsameth]

Zo veel dit. Je bent verandwoordelijk voor de hele leverstraat, dat je het uitbesteed is je eigen keus maar waard je niet vrij van verantwoordelijkheid. Gelukkig is dat onder de GDPR nu ook afgedekt.

[Lucky0wn]

Ik kan je vertellen dat, tot op zekere hoogte transacties inzichtelijk zijn. De transacties die door de fraudedetectie algoritmes geflagd worden, moeten met de hand gecontroleerd worden. Zo'n transactie als deze met een verkeerde vervaldatum zal altijd gedetecteerd worden.

[Bender]

De frauduleuze transacties gebeurde (zoals ik het lees) niet via het ticketmaster systeem, maar de gegevens werden via ticketmaster bemachtigd.
Doordat de frauduleuze transacties via bijvoorbeeld andere webshops gebeurde, kan ticketmaster dit niet zien. En mogelijk dus ook niet zichtbaar bij de derde partij.

De bank ziet dit omdat het wel transacties zijn van dezelfde bank, maar dus niet via ticketmaster of de derde partij. Logischerwijs zien die niet de transacties bij banken.

[Lucky0wn]

Je ziet weldegelijk de transacties, hiervoor hoeft TM alleen maar in te loggen bij hun
PSP

[incaz]

Het lek werkte als volgt:
- een klant gaat naar ticket master en bestelt kaarten
- komt terecht op de betaalpagina en geeft de credit card gegevens
- in dat venster leest de chatbot mee, die een kopietje van alle input (dus kaartnummer, vervaldatum, ccv) doorstuurt naar een server in de de VAE
- vervolgens worden die gegevens later op andere sites gebruikt voor betaling

De tickets van Ticket Master worden echter gewoon betaald en de klant en Ticket Master merken hier in eerste instantie niets van. Pas tijden later, als de cc wordt misbruikt, komt dit bij de bank van de klant terecht. En Ticket Master heeft geen enkele manier om dat na te gaan.

De onjuiste vervaldatum was geen fraude maar gewoon een vergissing door de gebruiker zelf. En ja, dan ketst die betaling, maar dat is geen probleem, dat is precies hoe het hoort. Zowel gebruiker als Ticket Master zien daar nog steeds niets geks in, alleen maar dat de betaling niet gelukt is.

Verdacht is het omdat precies die vergissing ineens weer terugkomt bij een frauduleuze overboeking. Waar hebben de fraudeurs dat vandaan? Van het meeluisteren op Ticket Master dus, dat is de enige plek waar die vergissing is gemaakt. Dat is wel een hele sterke aanwijzing dat er een link is tussen de fraude en de site van Ticket Master.

[Lucky0wn]

Dat is waar, weet precies hoe het verkeer loopt ben zelf wekzaam in de ticketing, vandaar dat ik ook precies weet wat je kan zien en wat niet

[incaz]

Dus, hoe kan Ticket Master zien dat er op een totaal andere overboeking gemaakt is op een andere plaats?

[Lucky0wn]

Zolang het bij dezelfde psp gebeurt, kan dit door de detectie algoritmes bepaald worden, daarbuiten natuurlijk niet. De gegevens zijn daarbij niet direct inzichtelijk natuurlijk

[Bender]

Dan ga je er van uit dat de transacties gebeuren via TM maar daar verteld het nieuwsbericht nergens over.

De transacties vinden plaats bij een bank, die meld het. De transacties kunnen dus bij webshops zijn over de hele wereld en TM ziet echt niet de transacties van zijn klanten bij bol.com.

[Verwijderd]

TM had gewoon eigen site kunnen bezoeken en met wireshark kijken wat er aan scripts wordt geladen en welke verbindingen er vanuit de browser worden gemaakt naar buiten. Het artikel zegt dat de lek in een script van ibarra zat. Ibarra is verantwoordelijk voor de bug maar klanten hebben met ticketmaster te maken dus vanuit klant is tm verantwoordelijk voor hun onderaannemers en leveranciers. Tm moet die verantwoordelijkheid proberen te verhalen bij onderaannemers maar dat is tussen tm en ibarra. De klant heeft niks met ibarra te maken, alleen met tm, dus die blijft eindverantwoordelijke, anders kunnen ze wel voor een 12 jarige ZZP'er kiezen en schuld bij hem gaan leggen. Zo werkt het niet. Tm moet kwaliteit testen en risicoanalyse doen want wat de site met de script doet bepaalt wel degelijk een groot deel van het risico. Als tm met wireshark en browserlogs hele keten had doorlopen hadden ze het kunnen zien, en niemand anders had die verantwoordelijkheid of mogelijkheid om de hele tm bestelling te doorlopen.

[Lucky0wn]

Dat is zeker waar, maar transacties bij TM zelf wel hoor!

[ajolla]

Ze hebben het pas serieus genomen toen het beveiligingsteam van Monzo bij hrn op bezoek kwam. Rijkelijk nalatig laat, vind ik.

[Bender]

Waarop baseer je dat ze het niet serieus hebben genomen?

Ze hebben waarschijnlijk wel verzoek gedaan bij hun leverancier, leverancier zegt dat ze niks opmerkelijks hebben kunnen vinden.
In welk opzicht is TM dan nalatig?

[ajolla]

Gezien het feit dat het balletje pas ging rollen ná het bankbezoek.
Ze hebben toen dus iets gedaan dat ze na de eerste melding hebben nagelaten te doen.

[Bondye]

Tja hacks/fraude/backdoors zijn tegenwoordig een rage.

In hoeverre kan TicketMaster dan voor nalatigdheid gestrafd worden?

En wat zou die straf dan zijn, een geldboete? Waar gaat dat geld dan heen?
Wie zijn er hier de dupe, juist, klanten die genoegen moeten nemen met een `We're sorry!`

[Kefke]

En wat zou die straf dan zijn, een geldboete? Waar gaat dat geld dan heen?
Wie zijn er hier de dupe, juist, klanten die genoegen moeten nemen met een `We're sorry!`

Jep, ik heb zo'n sorry mail gekregen van Ticketmaster. Gelukkig gebruik ik voor elke site een ander password, heb mijn password nu aangepast, maar stel dat ik vreemde frauduleuze transacties op mijn bankrekening merk, wat dan? Wie moet ik dan contacteren? Kan ik dan een schadevergoeding eisen van Ticketmaster (het is immers door hun fout dat ik tijd verlies om die frauduleuze transacties terug betaald te krijgen)?

Stiekem hoop ik dat bij een volgend datalek de CEO en hele raad van beheer ook hun gegevens getolen worden en die mannen daar enorm véél last door krijgen omdat ze te maken krijgen met identiteitsfraude en creditcard fraude. Misschien gaan ze dan eens beter nadenken over de beveiliging.

[Bondye]

Inderdaad, dit is iets waar ik dus al jaren tegenaan loop.

Zo zit mijn mailbox vol met dit soort `We're sorry, your data is stolen` mailtjes.
En ik ben zeker niet de enige: 10.000 datalekken 2017

Iedere keer een schijnheilige `sorry` naar klanten, hoge boetes worden opgelegd (waar dit geld beland is voor mij een vraag), maar geen enkele keer ontvangt de klant een compensatie.

Als klant mag je het lekker zelf uitzoeken door een jurist in te schakelen.

[Tjerkhazeveld]

Passwoord aanpassen is niet voldoende. CM bellen en cc laten blokkeren. Bij mij zijn twee frauduleuze transactie geblokkeerd deze week. De dag voordat de TM e mail kwam.
Overigens wel knap dat ze dit als onbetrouwbare betaalverzoeken kunnen herkennen als de fraudeur wel alle cc gegevens heeft.

[Verwijderd]

Als ik de creditcard maatschappijen was had ik TicketMaster verantwoordelijk gesteld voor de verliezen die zij leiden, want uiteindelijk komt de financiële last op hen neer. De klanten krijgen hun geld meestal terug van de creditcard maatschappijen.

[bArAbAtsbB]

en daar is de CM weer voor verzekerd....dus...de keten gaat altijd verder dan je denkt!

[BiLLY_daKid]

Daar is de cm niet voor verzekerd, maar dat zit in de fee die winkeliers moeten betalen. De boete bij PCIDSS non-compliance (aannwinkelierszijde) kunnen hard oplopen, enerzijds omdat aan issuing zijde (consument) nieuwe passen moeten worden uitgegeven en anderszijds flinke reputatieschade.

[Blokker_1999]

Zonder te weten welke stappen ze bij Ticketmaster ondernomen hebben en of daarbij fouten zijn gemaakt kan men niet oordelen over eventuele nalatigheid. Uiteindelik werd het lek wel gevonden, maar pas veel later. Het is niet omdat iemand komt melden dat je mogelijks een lek hebt dat je daarmee ook direct het probleem kunt vinden.

[lighting_]

Daar ben ik het niet helemaal mee eens.
Er staat Monzo was overtuigd dat er een data lek en meldde dat aan TM.
TM heeft wel/niet opgepakt. Het feit is dat het 76 dagen later pas een melding maakte.
Ik vind dat voor zo een groot bedrijf rijkelijk laat en zeker als een Bank dit aan jou vermeld.

[corpscoder]

Ik verwacht dat hier sprake is van een gedeelde verantwoordelijkheid, waar het meerendeel bij de derde partij zal liggen. Er is zeker een argumentatie te voeren mbt nalatigheid van ticketmaster aangezien Monzo zoveel concreet bewijs had dat er bij hun iets niet klopte.

[bArAbAtsbB]

en dus niet alleen slachtoffer van een datalek, maar ook nog eens van een organisatie die deed alsof er niets ad hand was!

[Blokker_1999]

Ticketmaster heeft ook voor een stuk gelijk. Het probleem zat niet bij hen maar bij software van derden. Het is niet alsof ze het wilden toedekken, het is dat ze op hun eigen systemen niets vonden en daarna niet goed genoeg hebben gekeken naar de diensten die ze extern afnamen.

[anboni]

Dan heeft Ticketmaster misschien geluk dat het voor 25 mei speelde. Als TM derde partijen inschakelt om voor hun iets met persoonsgegevens te doen, dan is TM nog steeds 100% verantwoordelijk voor die persoonsgegevens.

[debroervanhenk]

Maar als ze het nu pas bekend maken, zijn ze dus al sinds 25 mei strafbaar in overtreding (ze moeten een lek immers binnen 72 uur bekendmaken, en het is al eind juni). Wat dat betreft worden ze hopelijk nog steeds aan de hand van de AVG beboet.

[Blokker_1999]

Van zodra zij een vermoeden hebben dat er een lek is hebben ze 72u om dit bij de toezichthouder te melden, niet bij de getroffen klant. De klant kan wachten tot er voldoende details bekend zijn om deze correct te kunnen informeren.

[debroervanhenk]

Daar heb je natuurlijk een punt, maar ik heb het vermoeden dat ze de toezichthouder ook niet op de hoogte hebben gebracht, zeker omdat ze tegenover de bank beweerden dat er niets aan de hand was.

Voor de volledigheid, dit staat er in de verordening:

De verwerkingsverantwoordelijke moet de betrokkene zonder onredelijke vertraging in kennis stellen van de inbreuk in verband met persoonsgegevens wanneer die inbreuk in verband met persoonsgegevens grote risico's voor de rechten en vrijheden van de natuurlijke persoon met zich kan brengen, zodat hij de nodige voorzorgsmaatregelen kan treffen. De kennisgeving dient zowel de aard van de inbreuk in verband met persoonsgegevens te vermelden als aanbevelingen over hoe de natuurlijke persoon in kwestie mogelijke negatieve gevolgen kan beperken. Dergelijke kennisgevingen aanetrokkenen dienen zo snel als redelijkerwijs mogelijk te worden gedaan, in nauwe samenwerking met de toezichthoudende autoriteit en met inachtneming van de door haarzelf of door andere relevante autoriteiten, zoals rechtshandhavingsautoriteiten, aangereikte richtsnoeren. Zo zouden betrokkenen bijvoorbeeld onverwijld in kennis moeten worden gesteld wanneer een onmiddellijk risico op schade moet worden beperkt, terwijl een langere kennisgevingstermijn gerechtvaardigd kan zijn wanneer er passende maatregelen moeten worden genomen tegen aanhoudende of soortgelijke inbreuken in verband met persoonsgegevens.

Vaag genoeg, maar ik denk dat “fraude met bankpassen” geldt als “onmiddellijk risico op schade” en dat twee maanden wel erg lang is om passende maatregelen te nemen.

[Blokker_1999]

Natuurlijk zijn zij mede verantwoordelijk. Maar je kan als klant niet zomaar alle systemen van je externe dienstverlener gaan controleren. Je moet als klant al enorm veel macht hebben en belangrijk zijn voor die leverancier om zoiets te kunnen afdwingen. We weten niet of TM vragen heeft gesteld aan de leveranciers en welke reactie hierop is gekomen.

[EraYaN]

Je kunt wel een overeenkomst met de leverancier sluiten, je MOET zelfs onder de AVG. En daar staan aller handen dingen in over systemen, veiligheden, garanties, procedures, audits, datastromen, noem het maar op. Dus dat kan je als klant zeker wel afdwingen. Zelfs ieder persoon die ook maar enig zins de mogelijkheid kan hebben aan de data te geraken moet genoemd worden en gelogd als die gene aan de data zit etc.

[Darkstriker]

Data is wel erg makkelijk. Consumenten zijn klant van Ticketmaster en zij zijn daardoor eindverantwoordelijk. Dat zij niet goed nagegaan zijn of dit mogelijk bij derden wel gebeurde is hen net zo kwalijk te nemen als wanneer het intern gebeurde!

[kimborntobewild]

Ticketmaster heeft ook voor een stuk gelijk. Het probleem zat niet bij hen maar bij software van derden. Het is niet alsof ze het wilden toedekken, het is dat ze op hun eigen systemen niets vonden en daarna niet goed genoeg hebben gekeken naar de diensten die ze extern afnamen.

Een deel van de software is gemaakt door derden, maar het is ingebed in een betaalpagina van Ticketmaster; en daarmee is 't uiteindelijke product: software van Ticketmaster. Inbenta zegt: de software van Inbenta is door Ticketmaster op een manier gebruikt die niet veilig is.
Ik denk dat Inbenta hier gelijk heeft: als ik van her en der stukken code verkrijg en dit zelf ergens samenvoeg tot één geheel en dat vervolgens live breng, ben ik diegene die behoort te weten of de code veilig is. En als je de expertise niet hebt om dat te controleren, dan moet je het systeem in zijn geheel uitbesteden ('t liefst aan een partij die zijn sporen al verdiend).
Je zou het wellicht een beetje kunnen vergelijken met de verkoper van een keukenmes: de koper kan het mes op een verkeerde (illegale) manier gebruiken. Of: de eigenaar (Ticketmaster) van een lemmet heeft een externe partij (Inbenta) gevraagd er een handvat voor te maken.

[Reactie gewijzigd door kimborntobewild op 22 juli 2024 15:55]

[Verwijderd]

Geef ze een paar honderd miljoen euro boete als schot voor de boeg!!

Het blijkt dat ze een chatbot zelf hebben aangepast waardoor deze kwetsbaar werd voor overnames. Weer het werk van incompetent en te goedkoop ICT personeel.

En wat krijg je als klant? Een mailtje om je wachtwoord te veranderen en het advies om je bank afschriften goed na te kijken. Daarna is het voor hen afgedaan, vinden ze.

Het is juist voor dit soort prutswerk dat de GDPR is uitgevonden en is er de mogelijkheid om hoge boetes te kunnen opleggen. Er is te weinig besef of verantwoordelijkheid bij sommige bedrijven over de klantgegevens die zij beheren!

[Reactie gewijzigd door Verwijderd op 22 juli 2024 15:55]

[n00bje]

Als ik jou link volg en ook de security FAQ lees interpreteer ik het als volgt:

Inbenta heeft een chatbot ontwikkeld en deze aangepast voor TicketMaster.
Deze bot (enkele JS bestanden) wordt gehost bij Inbenta en TicketMaster linkt ernaar.
Vervolgens heeft een aanvaller toegang weten te krijgen tot de systemen van Inbenta en heeft de chatbot aangepast om data te ontfutselen.

[Verwijderd]

Het chatbot script was rechtstreeks geïntegreerd in de payments pagina, niet in een IFRAME. Dat betekent dat het chatbot script dus ook bij de payment gegevens kon.

Het is mij niet meteen duidelijk hoe derden dan het script van de bot konden modificeren of payment gegevens konden uitvragen. Waarschijnlijk zat er een dynamisch element in het script waarmee je script snippets kon injecteren via input.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 15:55]

[bassekeNL]

Tussen december 2017 en april 2018? Die tijdslijn komt niet overeen met wat Inbenta zegt over het nu bekende lek, zij hebben het over februari t/m juni 2018.

Kan dit een ander lek betreffen?

[S0epkip]

Sorry maar ik vind dit artikel heel onduidelijk geschreven, eigenlijk is het niet te volgen wat de tijdslijn en boodschap nu is. Hebben meer mensen hier last van of ligt dit toch aan mij?

[WhiteDog]

Ticketmaster (geen klein bedrijf) wordt door jullie wel hard aangepakt hoor. Ook allerlei aannames over wat ze wel en niet gedaan zouden hebben. Je zou bijna vergeten dat zij hier ook gewoon het slachtoffer zijn en schade lijden? Over strenge straffen voor de criminelen en dat de politie er achteraan moet gaan lees ik hier niks.

[incaz]

Ticket Master toont zich hier gewoon niet erg proactief in. Waarom moeten we daar begrip voor hebben? (En verder is TM natuurlijk een vervelend bedrijf met hun belachelijke service charges en het opkopen van hun eigen tickets door een dochterbedrijf om het vervolgens tegen nog meer geld te verkopen. Het is blijkbaar niet verboden, maar het geeft wel ongeveer aan welke waarden TM erop na houdt.)

Maar zonder dat mee te laten spelen:
- er zit nogal een groot gat tussen de eerste meldingen van fraude in april, en het naar buiten komen van de gegevens nu
- er zit een gat tussen de melding van een malicious script aan Ticketmaster_NZ in mei, en het naar buiten komen van het probleem nu
- de verklaring die TM aflegt is inhoudelijk nogal mager en geeft ook niet duidelijk aan dat er al veel mensen slachtoffer zijn geworden van onrechtmatige afboekingen via gestolen credit card-informatie
- ze bieden een 'monitoring dienst' aan via een link die vooral aan phishing doet denken, a.pgbt.me/someID, zonder enige informatie wat het doet of wie het is. Wel mag je nog een keer gevoelige informatie doorgeven. (Handig voor scammers! Want na dit soort lekken heb je niet alleen de oorspronkelijke fraude, maar ook nog eens een boel opportunistische andere scammers die proberen daar wat van mee te profiteren. Dus wat kan er mis zijn met het posten van een volstrekt oncontroleerbare dienst die je naam en emailgegevens wil hebben?)

De harde aanpak lijkt me dus helemaal prima en door en door verdiend.