Beveiliging
Bewijs dat je browser geen kluis is.
Chrome en Firefox slaan je wachtwoorden op — en geven ze vervolgens aan elk programma dat als jou draait. Dat is geen bug. Dat is het ontwerp. Hier is het bewijs: eerst in duidelijke taal, dan in code.
De versie in duidelijke taal
De "wachtwoordbeheerder" van je browser wordt beschermd door precies één slot: je computerlogin. Zodra je bent ingelogd op je laptop, kan de browser direct elk opgeslagen wachtwoord lezen — dus alles wat anders op je account draait, kan dat ook.
Een slechte download. Een verdacht browsertje. Eén vergiftigd pakket in een project dat je hebt gekloond. Zodra het draait — terwijl je bent ingelogd, zoals je altijd bent — leest het elk wachtwoord dat je browser heeft opgeslagen, in de tijd die het kost om een bestand te openen. Er is geen hoofdwachtwoord om te kraken, want er is niets te kraken: de browser is gebouwd om automatisch voor je te ontgrendelen, en de malware vraagt het gewoon netjes als "jou".
Dit is niet theoretisch. Het is de meest voorkomende manier waarop gewone mensen hun accounts verliezen. De malware heeft zelfs een saaie industrienaam — "info-stealers" — omdat het zo routineus is. Je wachtwoorden, je opgeslagen kaarten, je sessiecookies: gekopieerd en weg voordat je het merkt.
De oplossing is simpel te formuleren: je wachtwoorden moeten vergrendeld zijn met iets wat de rest van je computer niet heeft — en ze mogen helemaal niet op de machine staan.
De versie met bewijsstukken
Geloof ons niet zomaar. Chromium en Firefox zijn open source, en het leespad is gedocumenteerd, standaard en kort. Hier staat precies waar de wachtwoorden zijn en hoe ze eruit komen.
Chrome (en elke Chromium-browser)
Chrome slaat logins op in een SQLite-database — Login Data, tabel logins, kolom password_value — versleuteld met AES-256-GCM. De AES-sleutel bevindt zich in Local State, "beschermd" door het besturingssysteem: DPAPI op Windows, de login Keychain op macOS, gnome-keyring/kwallet (of platte tekst) op Linux.
Lees het zelf — de code is open. Zoek in Chromium naar de constante die de verpakte sleutel tagt: kDPAPIKeyPrefix in os_crypt. De sleutel is DPAPI-verpakt, getagd en opgeslagen — vervolgens uitgepakt met één enkele aanroep die niets beschermt tegen jou:
const char kDPAPIKeyPrefix[] = "DPAPI";
CryptUnprotectData(&intermediate, /*ppszDataDescr=*/nullptr,
/*pOptionalEntropy=*/nullptr, nullptr, nullptr, 0, &output);Geen tweede geheim, geen wachtwoord, geen prompt. CryptUnprotectData geeft de sleutel terug aan elk proces dat in je sessie draait — wat precies het dreigingsmodel is dat DPAPI documenteert: als het als jou draait, ben jij het. De hele taak van de aanvaller bestaat uit drie regels: lees de sleutel uit Local State, pak deze uit, AES-GCM-ontsleutel elke rij in Login Data. Info-stealer malware doet dit al jaren.
"On-device encryptie" redt je ook niet
Googles antwoord is een 6-cijferige pincode die je gesynchroniseerde kluis versleutelt. In mei 2026 lieten onderzoekers van Phishu zien hoe dun dat is. Een overtuigende nep-Google-login — adversary-in-the-middle phishing — onderschept de sessie en die pincode, en de pincode is de hoofdsleutel tot elk wachtwoord en elke passkey in het gesynchroniseerde account. Daarmee voegt een aanvaller zijn eigen apparaat toe aan je Google "beveiligingsdomein" en de hele kluis synchroniseert rechtstreeks naar hen — volledige overname in één stap.
De ontwerpfout: Google staat toe dat een apparaat wordt toegevoegd op basis van alleen de 6-cijferige pincode, zonder goedkeuring van een apparaat dat je al bezit.
Firefox
Firefox bewaart logins in logins.json en de sleutel in key4.db, ontsleuteld door NSS's "Secret Decoder Ring" — ook open source: security/nss/lib/pk11wrap/pk11sdr.c. Als je een Primary Password instelt, wordt de sleutel daarmee verzegeld.
Standaard heb je dat niet — dus de sleutel is verzegeld met de lege string, en een opgeslagen "password-check" waarde bevestigt dat een leeg wachtwoord deze ontsleutelt. Kopieer twee bestanden uit je profiel (key4.db + logins.json), wijs NSS of de open-source firepwd.py ernaar, en ze worden ontsleuteld. Een slot waarvan de sleutel aan de deur is geplakt, is geen slot.
Elke browserwachtwoordopslag heeft dezelfde structuur: het geheim bevindt zich waar je werkt, ontgrendeld door de sessie waarin je al bent. Versleuteling die de rest van je eigen computer kan ongedaan maken, beschermt je niet tegen de dreiging die accounts daadwerkelijk leegrooft — code die als jou draait.
Waarom Clavitor niet op deze manier gelezen kan worden
Clavitor bewaart je kluis niet op de machine. Er is geen Login Data, geen key4.db, geen sleutel in Local State — niets op schijf dat een proces dat als jou draait kan scrapen.
De ontsleutelingssleutel is niet verzegeld met je OS-login. Het wordt afgeleid van een hardware-tik — Touch ID, Face, of een YubiKey — berekend in de browser, gebruikt voor één enkel verzoek, en vervolgens weggegooid. Inloggegevens worden opgehaald via een scoped API precies wanneer je erom vraagt, en nooit gecached. Malware die als jou draait, vindt een lege kast.
Dat is het verschil tussen "versleuteld op je apparaat" en "helemaal niet op je apparaat".
Stop met je wachtwoorden aan de browser toe te vertrouwen.
De Clavitor-extensie vult aan zoals je browser dat doet — en bewaart de kluis ergens waar je laptop het niet kan lezen.