Security (b)log: februari 2026

vrijdag 27 februari 2026

Oliedom

Afbeelding via Unsplash

Meestal zijn datalekken en hacks ongemakken die anderen overkomen. Deze keer is de kans groot dat je zelf beteuterd naar een mailtje van je telecomprovider zit te kijken. Odido heeft namelijk ongeveer een derde van de Nederlandse mobiele markt in handen. Daarnaast leveren ze vaste internetaansluitingen aan een miljoen huishoudens. Ook als klant van Ben ben je trouwens het haasje.

Het nieuws wordt breed uitgemeten in de media. Dat komt natuurlijk in eerste instantie door de omvang: het gaat om 6,2 miljoen accounts, die de criminelen uit het klantcontactsysteem hebben gestolen. Daar zitten ook accounts bij van mensen die al jaren geen klant meer zijn van Odido, ontdekte het bedrijf doordat deze mensen bevreemd reageerden op de mail waarin het bedrijf hen inlichtte over de diefstal. Maar de omvang is niet de enige reden om zenuwachtig te worden. Ook wát er gelekt is draagt daaraan bij. Het gaat namelijk niet alleen om de ‘gebruikelijke’ gegevens zoals naam, adres en e-mailadres. Bij deze hack zijn ook telefoonnummers, bankrekeningnummers, paspoortgegevens en BSN’s buitgemaakt. En informatie over betalingsachterstanden.

Ongeveer twee miljoen records, met bijna 700 duizend unieke e-mailadressen, zijn inmiddels gepubliceerd, omdat Odido niet aan de eis van ShinyHunters, zoals de criminelen zich noemen, heeft voldaan om ‘een laag 7-cijferig bedrag’ (dus minimaal een miljoen euro) te betalen. En ze dreigen met publicatie van nog meer gegevens. Reden genoeg voor miljoenen mensen om zich zorgen te maken.

Uit de berichtgeving omtrent deze hack spreekt vooral medeleven met Odido en zijn klanten. Waar je in de grote media minder over hoort is de vraag hoe dit heeft kunnen gebeuren. Ik snap ook wel dat ze zich op de slachtoffers richten. Maar toch: hoe heeft dit kunnen gebeuren?

Phishing, beste mensen. Ik hamer er in alle presentaties steeds weer op hoe belangrijk het is dat iedereen weerbaar is tegen deze vorm van cybercrime. Bij Odido is dat deze keer niet gelukt. De phish kwam terecht bij medewerkers van de klantenservice (mogelijk bij een callcenter in het buitenland), die erin trapten en hun wachtwoord prijsgaven. Ook tweefactorauthenticatie (2FA) bleek geen hindernis te zijn: de criminelen belden de medewerkers op en deden zich voor als collega’s van de ICT-afdeling. Zo kregen ze ook de tweede factor in bezit en konden ze inloggen. ShinyHunters heeft hier een mooi staaltje social engineering gepleegd: ze hebben niet het computersysteem gehackt, maar de computergebruikers.

Vervolgens gingen ze gegevens downloaden. Heel veel gegevens. Daar had een automatische noodrem op moeten zitten. Het kan immers nooit de bedoeling zijn dat via een account van de klantenservice zoveel gegevens tegelijk worden gedownload. Het lijkt erop dat daar niet op werd gemonitord. Dat zou betekenen dat niet alleen de organisatorische maatregelen (training) hebben gefaald, maar ook de technische. Dat de training heeft gefaald, kun je bijna niemand kwalijk nemen. Want een zorgvuldig opgestelde phish is nauwelijks van echt te onderscheiden. Oh, wat zou ik deze phish graag eens willen zien. Dat de medewerkers ook hun 2FA opgaven, is trouwens wel een dingetje dat extra aandacht behoeft.

Odido zelf houdt zich erg op de vlakte. Ik verwachtte eigenlijk een melding op de homepage van hun website, maar pas na het nodige graafwerk vond ik de Informatiepagina cyberincident Odido. Daar staat eerst een bijzonder kort officieel statement over de kwestie. Eronder maken ze in koeienletters reclame voor de gratis bescherming tegen onder andere phishing die ze hun klanten bieden (zouden ze die zelf ook gebruiken…?). Pas daarna volgt uitvoerige uitleg over wat er aan de hand is, wat je kunt doen en wat je moet laten. De strekking van het verhaal is dat criminelen, die over de gelekte informatie beschikken, jouw identiteit kunnen aannemen en daarmee op jouw kosten van alles kunnen regelen. Kijk de komende tijd vooral scherp naar facturen die je ontvangt, en check je bankrekening op incasso’s die je niet herkent.

In de veelgestelde vragen werpen ze zelf de vraag op of de beveiliging bij Odido op orde was, maar ze beantwoorden de vraag niet echt. Er staan alleen de gebruikelijke gemeenplaatsen: veiligheid is onze topprioriteit, we werken continu aan verbetering, maar ja, die criminelen zijn ook best wel slim hè.

In de reclametune van Odido zit een mama appelsap (ook wel mondegreen genoemd; je weet wel, dat je (vooral in een liedje) iets anders hoort dan de feitelijke tekst). In de tune wordt de naam van het bedrijf gezongen (‘O-di-do’), maar als je wilt kun je ook verstaan: o-lie-dom. Of Odido inderdaad oliedom was bij het beveiligen van zijn systemen, zal ongetwijfeld worden onderzocht. Maar het is de vraag of wij dat ooit te horen krijgen.

En in de grote boze buitenwereld …

… was ik vandaag helaas te druk met andere zaken om deze rubriek te kunnen vullen.

woensdag 18 februari 2026

Lengte loont

Klik op de afbeelding voor een grote versie

Deze week is de Security (b)log er iets eerder vanwege een paar vrije dagen

Precies een jaar geleden stelde collega Alexander een vraag. Sommige onderwerpen liggen wat langer te rijpen. De vraag gaat over wachtwoorden en de wenselijkheid om die lekker ingewikkeld te maken. Hij stuurde een bekend schema mee dat bedoeld is om inzichtelijk te maken hoe snel wachtwoorden kunnen worden gekraakt. Ik zal het schema voor je ontleden, want het bevat veel interessante informatie.

Ik begin met de kop. Daarin is de term ‘brute force aanval’ van belang: letterlijk een aanval met brute kracht. Maar waarop dan? Kijk, een systeem waarop jij wilt inloggen, heeft een bestand waarin alle accounts staan. Het systeem moet immers kunnen controleren of je erin mag. Tenzij de ontwerper van zo’n systeem onder een steen heeft gelegen, staat het wachtwoord daar niet leesbaar in. Want dan zou iemand, die het bestand met accounts weet te bemachtigen, vrij spel hebben. Nee, de wachtwoorden zijn versleuteld opgeslagen. Als jij inlogt, dan wordt het wachtwoord, dat jij invult, eveneens versleuteld. Zo kan het toch vergeleken worden met het opgeslagen wachtwoord.

Een aanvaller heeft veel pogingen nodig om je wachtwoord te kraken. Als hij gewoon maar begint om op een website met jouw account in te loggen, wordt je account bij de meeste systemen na een aantal foute pogingen vergrendeld (‘gelockt’). Dat is dus een beveiligingsmaatregel tegen brute forcing. Dat schiet niet op voor die aanvaller. Hij wil dan ook liefst het complete wachtwoordbestand in handen krijgen, zodat hij er offline rustig op los kan proberen zonder telkens gelockt te worden. Daarvoor moet hij natuurlijk wel eerst even inbreken op zijn doelwit.

Laten we ervan uitgaan dat hij het bestand heeft weten te bemachtigen. Hij gebruikt vervolgens een krachtige computer om de accounts in dat bestand aan te vallen. Het schema geeft aan hoeveel tijd daarvoor nodig is. Verticaal loopt de lengte van de wachtwoorden op van vier naar achttien. Horizontaal loopt het aantal verschillende tekens, waaruit het wachtwoord kan bestaan, steeds verder op. In de eerste kleurrijke kolom zijn er slechts tien verschillende tekens: de cijfers nul tot en met negen. In de volgende kolom zijn het er al 26, vervolgens 52 en dan 62. In de laatste kolom, die staat voor alle mogelijk tekens – cijfers, hoofd- en kleine letters, symbolen (! @ # $ % ^ & * ( ) - _ = + enz.) – hebben we het meestal over 94 tekens (‘printable ASCII’).

Linksboven zie je dat een wachtwoord dat uit vier cijfers bestaat geen weerstand biedt. Er zijn slechts tienduizend verschillende wachtwoorden mogelijk, wat betekent dat de aanvaller gemiddeld vijfduizend pogingen moet doen. Een fluitje van een cent. Rechtsonder vind je het andere uiterste: achttien tekens lang, gekozen uit 94 tekens. Daarmee kun je 3,28 x 10³⁵ verschillende wachtwoorden maken – dat is grofweg een drie met 35 nullen. Die krachtige hackcomputer doet er volgens de tabel 463 triljoen jaar over om het te kraken. Een triljoen is duizend miljard; het universum is slechts 13,8 miljard jaar oud.

Wat ik veel interessanter vind, is dat er in de tabel verticaal meer gebeurt dan horizontaal. Met andere woorden: lengte is veel belangrijker dan het aantal mogelijke tekens. Als je een wachtwoord van alleen cijfers vier keer zo lang maakt, dan heeft de boef al tweeduizend jaar nodig. Daarentegen heeft uitbreiding van het aantal mogelijke tekens (bij gelijke lengte) geen noemenswaardig op de kraaksnelheid. En als je kijkt naar de regel van vijftien karakters, dan zie je dat het kraken van een wachtwoord, dat alleen uit kleine letters bestaat, al bijna een half miljard jaar duurt (en wat mij betreft had dat vakje gerust groen mogen zijn).

Conclusie: als een wachtwoord lekker lang is, dan hoef je je niet druk te maken over de complexiteit ervan. Met andere woorden: veel systemen eisen dat je minimaal 1 cijfer, 1 kleine letter, 1 hoofdletter en 1 symbool gebruikt, maar dat is niet nodig, mits je wachtwoord lang genoeg is. Die lange wachtwoorden laat je comfortabel genereren en beheren door je password manager. Wachtwoorden, die je daar niet in kwijt kunt – bijvoorbeeld het hoofdwachtwoord van je password manager – kies je zo, dat jij ze wel kunt onthouden, maar iemand anders ze niet gemakkelijk kan raden. Bijvoorbeeld ‘Mijn wachtwoord hack je niet’ of ‘iz2bbsodw1wtewbw’ (ik zag 2 beren broodjes smeren…).

En in de grote boze buitenwereld …

vrijdag 13 februari 2026

Op de bon

Foto van auteur

Kom je wel eens in Duitsland? En heb je daar wel eens een kassabon van dichtbij bekeken? Nou, ik wel. En toen viel mij meteen de cryptografische informatie op die erop stond.

Voor de duidelijkheid: als ik het over crypto heb, dan praat ik over cryptografie en niet over digitaal geld, zoals de bitcoin. Cryptografie: de wiskundige kunst van het beveiligen van gegevens, zei laatst iemand op een congres. Maar wat stond er dan precies op die bon, en vooral: waarom?

Het waren lange reeksen cijfers en letters, zoals je op de foto kunt zien. Mijn aandacht werd getrokken door de ‘PublicKey’-rubriek helemaal onderaan de bon. Daarachter een brij van 132 tekens. De bon bevat in nog zo’n zelfde weergave een digitale handtekening (signature). Je ziet niet vaak dergelijke informatie over digitale handtekeningen op een analoog medium (de papieren bon).

Het zit ‘m in de Duitse wetgeving, de Kassensicherungsverordnung (Kassabeveiligingsverordening, ietwat vreemd afgekort tot KassenSichV). Daarin staat dat elektronische kassa’s voorzien moeten zijn van een Technische Sicherheitseinrichtung (TSE – Technische Beveiligingsvoorziening). Die TSE voorkomt dat er met de kassa gerommeld kan worden: alle transacties worden, met een volgnummer, gelogd en digitaal ondertekend. Zo kan het Finanzamt (de belastingdienst) controleren op onregelmatigheden, zoals ontbrekende bonnen. Als een kassa geen gecertificeerde TSE heeft, kan de winkelier een boete tot 25.000 euro krijgen.

Die cryptografische bewerking speelt zich binnen de kassa af. Maar waarom staat die informatie ook op de bon? Omdat die bon zelf ook controleerbaar moet zijn. Jij als klant doet daar niets mee – beschouw het feit, dat die gegevens mij opvielen, gerust als beroepsdeformatie. Maar de fiscus kan steekproeven doen, bijvoorbeeld door een mystery guest te laten shoppen en vervolgens de bon te checken. Vroeger konden winkeliers de klant een keurige kassabon meegeven en toch transacties uit de kassa verwijderen of manipuleren. Dat kan nu niet meer, omdat de digitale handtekening dat meteen aan het licht zou brengen.

Op modernere kassabonnen is de uitgeschreven TSE-informatie vervangen door een QR-code. Dat maakt het leven van controleurs gemakkelijker (al wordt het aangeprezen als papierbesparende maatregel). Nóg milieuvriendelijker is de digitale kassabon, die heel on-Duits fiskaly receipt heet. De klant scant dan een QR-code op de kassa. Maar het kan ook eenvoudiger: bij de supermarkt, waar wij om de zoveel tijd heen gaan om dingen te kopen die ze hier niet hebben of die daar veel goedkoper zijn, kun je de kassabon rechtstreeks in de app van de winkel ontvangen.

Die digitalisering is mooi, maar ik zie wel een probleem. Als ik iets koop waar garantie op zit, dan scan ik de bon in en bewaar hem onder een zinvolle naam op de computer. Dat doe ik om twee redenen: originele bonnen vervagen en ik kan de computer voor mij laten zoeken. Digitaal verstrekte bonnen vind ik dan echter niet terug. Als je je dat realiseert, moet je vervolgens maar net weten bij welke winkel je het product hebt gekocht, om de bon vervolgens in de desbetreffende app of op hun website terug te zoeken. Om dat te ondervangen ga ik in dat soort gevallen nu maar een bestandje in mijn administratie opnemen waar ik in zet waar het product gekocht is. Nog een tip voor collega-administratieve nerds: omdat er aan kleding nog wel eens wat kapot wil gaan, bewaar ik bij de ingescande bon ook een foto van het kledingstuk. Dan weet je dat die bon bij die broek hoort.

Op de kassabon van Shawarma Al-Zaiem (ja, zo heet shoarma in het Duits) viel mij nog iets op: de tekst “Es bediente Sie: LPADMIN” (U werd geholpen door). Op de kassa was dus de beheerder ingelogd. Nou is Al-Zaiem een kleine zaak waar slechts twee mensen aan het werk waren, maar toch: inloggen als administrator (beheerder) om reguliere werkzaamheden uit te voeren is nooit een goed idee.

Stuur me foto’s van je verbaasde reisgenoten als jij bij je volgende bezoek aan Duitsland aandachtig de kassabon zit te bestuderen (-;

En in de grote boze buitenwereld …

vrijdag 6 februari 2026

Op glad ijs

Afbeelding via Unsplash

Er was ijzel voorspeld. Op de radar zag je een machtig neerslaggebied vanuit het zuiden opstomen. Net als veel collega’s besloot ik om eerder naar huis te gaan. Ik kwam droog en, belangrijker, zonder glibberpartijen thuis aan en zag de rest van de middag dat het in deze contreien allemaal zo’n vaart niet liep.

Na werktijd zou ik gaan hardlopen. Maar ja, de dreiging van ijzel hing toch nog in de lucht (al had ik van achter mijn veilige ramen niemand op z’n snufferd zien gaan). Daarom besloot ik niet buiten te gaan rennen, maar mijn hardloopband in stelling te brengen. Lekker veilig binnen sporten. Bijkomend voordeel: binnen was het zo’n twintig graden warmer dan buiten. Ik kon volstaan met een korte broek en een luchtig shirtje.

Na twaalf minuten en vijftig seconden kwam mijn sportiviteit abrupt tot een einde. Ik maakte een misstap: mijn rechter voet landde niet op de band, maar op de rand van het toestel. De rechter kant van mijn lichaam stond daardoor plotseling stil, terwijl de volgende stap – met links – al onderweg was. Je kunt je voorstellen dat dat niet goed afliep. Eerst landde mijn linker knie op de band, vervolgens de rechter. Mijn linker voet stond inmiddels op de grond, achter de loopband. Daardoor stond ik stil. Terwijl de band onder mij doordraaide. Met mijn knieën er nog op. Dat schuurde behoorlijk.

Nou heeft zo’n hardloopband een veiligheidskoord. Aan de ene kant zit een klem die je aan je kleding bevestigt, aan de andere kant een plug die je in het bedieningspaneel steekt. Als je valt, dan wordt die plug eruit getrokken, waardoor de band stopt, is het idee. Het koord bleek net iets te lang te zijn voor de positie waarin ik was terechtgekomen – de veiligheidsplug bleef op z’n plek. De band bleef draaien totdat ik met de hand aan het koord trok.

Vrouw en dochter waren snel en bezorgd ter plekke en ietwat beduusd vroeg ik om twee natte washandjes om mijn knieën mee te koelen. Links zie je er drie dagen later al bijna niets meer van, maar rechts mis ik momenteel zo’n vier centimeter vel. Allemaal niet dramatisch hoor, alleen af en toe wat branderig, en de genezende wond trekt een beetje.

Ik heb hier twee dingen van geleerd. Ten eerste: organisatorische maatregelen kunnen zich tegen je keren. Ik besloot om niet naar buiten te gaan omdat ik geen valpartij wilde. En precies dát gebeurde. Uiteraard probeer ik dat op mijn werk te projecteren (dit blijft de Security (b)log hè). Nemen we daar ook soms besluiten waardoor precies datgene gebeurt wat we willen voorkomen? Die besluiten zijn doorgaans weloverwogen, uit en te na bediscussieerd en we hebben er meerdere nachten over geslapen. We zijn momenteel bezig om aan de eisen voor wachtwoorden te sleutelen. Uiteraard met de bedoeling dat de accounts van onze medewerkers veiliger worden. Daarbij moeten we er goed op letten dat we het niet te moeilijk voor jullie maken, waardoor je ‘creatief’ gaat worden. Communicatie en ondersteuning zijn belangrijk bij wijzigingen die iedereen persoonlijk raken.

Ten tweede: als technische beveiligingsmaatregelen niet goed geïmplementeerd worden, dan werken ze niet onder alle omstandigheden. Het noodstoptouwtje werkt ongetwijfeld prima als je recht achteruit van de band kukelt, maar dus niet als je val halverwege stopt. Je moet goed weten met welk doel je een maatregel invoert, en je moet naar alle mogelijke scenario’s kijken. Alleen dan mag je verwachten dat de maatregel doet wat je verwacht. Voorbeeld: we versleutelen onze gegevens en onze communicatie al sinds jaar en dag. Maar als je bij de manier waarop je dat doet tegenwoordig geen rekening houdt met de komst van de quantumcomputer, waarvoor het kraken van die versleuteling een peulenschil is, dan ben je alsnog kwetsbaar. Misschien niet nu al, maar wel als de gegevens van vandaag over een paar jaar alsnog door onbevoegden kunnen worden gelezen.

Onze dochter viert vandaag haar achttiende verjaardag en ze wil graag met de auto naar school. We hebben allerlei maatregelen getroffen: ze heeft haar rijbewijs gehaald, daarna hebben we flink met haar geoefend en we hebben afspraken gemaakt. De auto is onlangs nog nagekeken. En we hebben ons vertrouwen uitgesproken. En toch ben je als ouders opgelucht als ze weer veilig thuis is. Omdat je weet dat maatregelen niet altijd werken.