De juiste generator, taal . Niet alle wachtwoordgeneratoren zijn gelijk — en de taal waarin je kluis is geschreven, is geen technisch detail. Een analyse van entropie, generatiemodi en waarom Rust zich onder de motorkap opdringt. Wanneer een beheerder “een sterk wachtwoord genereert”, zijn er twee vragen: is het echt onvoorspelbaar (de kwaliteit van de willekeur), en wat gebeurt ermee in het geheugen zodra het wordt weergegeven? Het eerste hangt af van de generatiemodi. Het tweede van de taal waarin de applicatie draait. Dit artikel behandelt beide. ~100 bits willekeurig wachtwoord van 16 tekens (zeer sterk) ~77 bits Diceware-passphrase van 6 woorden (EFF) 12,9 bits entropie toegevoegd per Diceware-woord (lijst met 7 776 woorden) Entropie: de enige maat die telt De sterkte van een wachtwoord wordt niet gemeten aan de hand van de ervaren “complexiteit”, maar aan de entropie : het aantal bits onzekerheid voor een aanvaller. Hoe meer mogelijke combinaties er zijn, hoe sterker de kosten van een brute-force-aanval oplopen. Een wachtwoord van 16 tekens uit het volledige ASCII-alfabet haalt ongeveer 100 bits — het domein van “zeer sterk”. Een cruciaal punt dat vaak wordt vergeten: entropie telt alleen als de bron van willekeur een CSPRNG is (cryptografisch veilige pseudo-willekeurige generator). Een klassieke Math.random() is voorspelbaar en maakt de rest waardeloos. Goede implementaties lezen entropie uit het besturingssysteem: /dev/urandom of getrandom(2) op Unix, CNG op Windows. Vier families van generatoren Een goede beheerder biedt niet “één” generator, maar meerdere modi die bij het gebruik passen. De regel: memoriseerbaarheid betaal je met lengte . Dit zijn de vier families, van het meest compact tot het meest menselijk. De juiste reflex: stem entropie af op het gebruik Voor een webaccount dat wordt beschermd door een loginpagina met snelheidsbeperking, wordt de aanvaller afgeremd tot enkele honderden pogingen per seconde: zelfs 50 bits houden dan geologische tijden stand. Over-entropie heeft alleen zin voor offline geheimen (encryptiesleutel, seed van een crypto-wallet), waar de aanval massaal parallel kan worden uitgevoerd. Voor zulke zeer waardevolle geheimen blijft het rollen van echte fysieke dobbelstenen (Diceware in de letterlijke zin) de ultieme optie: het neemt elke afhankelijkheid weg van de kwaliteit van de CSPRNG of van een gecompromitteerde browser. Waarom Rust het verschil maakt Een goed wachtwoord genereren is de helft van het werk. De andere helft: het niet laten rondslingeren . Zodra je wachtwoord wordt weergegeven of ontsleuteld, leeft het in het werkgeheugen — en daar wordt de taal van de applicatie bepalend. Microsoft rapporteerde dat 70 % van de beveiligingskwetsbaarheden die het tegenkomt geheugenbugs zijn (buffer overflow, use-after-free, enz.). Google zag dezelfde verhouding in Chrome en Android. Dit zijn precies de foutklassen die Rust bij compilatie elimineert via zijn model van eigendom ( ownership ) en lenen ( borrowing ), zonder garbage collector. De cijfers van Google spreken voor zich: geheugenkwetsbaarheden in Android daalden van 223 in 2019 naar minder dan 50 in 2024 , en kwamen voor het eerst onder de grens van 20 % van het totaal. Nieuwe Rust-code vertoont een dichtheid aan geheugenfouten die tot 1000× lager is dan historische C/C++-code, met bovendien 4× minder rollbacks en 25 % minder reviewtijd. 1. Geheugenveiligheid zonder garbage collector. Talen zoals Java of Python zijn memory-safe, maar hun garbage collector maakt geheugen niet-deterministisch vrij: een geheim kan er onbeperkt blijven bestaan, blootgesteld aan een memory dump of cold-boot-aanval. Rust geeft geheugen deterministisch vrij zodra de data niet meer wordt gebruikt. 2. Expliciet wissen met zeroize . Rust garandeert niet dat vrijgegeven geheugen wordt overschreven. De crate zeroize vult dat gat: door een geheim in Zeroizing te verpakken, garanderen we dat het met nullen wordt overschreven — via een volatile write die de compiler niet kan optimaliseren — precies op het moment dat het buiten scope gaat. 3. Een typesysteem dat correct cryptogebruik afdwingt. Het strikte typesysteem van Rust maakt het mogelijk af te bakenen hoe gevoelige data mag worden gebruikt — en hoe vaak. Je kunt bijvoorbeeld een sleutel modelleren die maar één keer mag worden gebruikt; de compiler weigert elk hergebruik. Technische eerlijkheid: Rust is geen toverstaf Code met unsafe en externe afhankelijkheden blijven aanvalsvlakken — Google heeft bijvoorbeeld een kwetsbaarheid (CVE-2025-48530) gecorrigeerd in een unsafe -blok van een Rust-parser voordat die in productie ging. Geheugenveiligheid is een laag , geen eindpunt: ze wordt gecombineerd met defense in depth (robuuste KDF zoals Argon2id, zero-knowledge-architectuur, automatische vergrendeling, MFA). Wat je van een beheerder moet eisen Bij het kiezen — of beoordelen — van een wachtwoordbeheerder zijn er vier concrete vragen: 1. Steunt de generator op een systeem-CSPRNG , en toont hij de entropie in bits? 2. Biedt hij een Diceware/EFF-passphrase-modus voor het hoofdwachtwoord? 3. Gebeurt de generatie lokaal (client-side) , zonder verkeer via een server? 4. Is de gevoelige kern geschreven in een memory-safe taal met expliciet wissen van geheimen? Veilige generatie. Een kluis gebouwd voor de lange termijn. Wachtwoorden met hoge entropie, memoriseerbare passphrases en een kern ontworpen voor geheugenveiligheid. Informatieve inhoud met educatief doel. De aangehaalde statistieken (Google/Android, Microsoft, Diceware/EFF) komen uit de hierboven vermelde bronnen. De Rust-codevoorbeelden zijn illustratief en vereenvoudigd.