Hoe we je wachtwoord opslaan (en waarom dat eigenlijk saai moet zijn)

Over wachtwoord-opslag zijn meestal twee soorten stukken te vinden: heel technische, of heel vage. Dit wordt geen van beide. Hier staat precies wat er met jouw wachtwoord gebeurt als je het bij Okidoky typt, waarom we bepaalde keuzes gemaakt hebben, en wat er zou gebeuren in het ergste geval.

De twee dingen die je nooit zou moeten doen

Twee vormen van wachtwoord-opslag zijn onaanvaardbaar in 2026, en beide komen helaas nog voor:

  1. Plaintext-opslag. Je wachtwoord staat letterlijk in de database als "koala1234". Ieder personeel lid, iedere database-backup, iedere SQL-injectie-aanval heeft direct toegang. Als je bij een service ooit een "wachtwoord herstel"-e-mail krijgt waarin je oude wachtwoord STAAT — dan doen ze dit. Verlaat die service.

  2. Versleuteling zonder hashing. De site versleutelt wachtwoorden met een sleutel die zij ook zelf hebben. Beter dan plaintext, maar als die sleutel ooit lekt (of gevorderd wordt), zijn alle wachtwoorden leesbaar.

Okidoky doet geen van beide. We gebruiken bcrypt-hashing, de industriestandaard sinds ~2008 en nog steeds een van de veiligste opties.

Wat bcrypt eigenlijk doet

Als je "mijnwachtwoord123" typt bij registratie of login, gebeurt dit op onze server:

  1. Salt genereren. Er wordt een willekeurige reeks van 16 bytes gemaakt, uniek voor jou.
  2. Hash berekenen. Jouw wachtwoord wordt met de salt door een wiskundige functie gehaald die opzettelijk TRAAG is (werkfactor 12 in onze setup = ongeveer 250ms per poging op moderne hardware).
  3. Opslaan. Alleen het resultaat — een string van 60 tekens die begint met $2b$12$ — gaat de database in, samen met de salt. Je originele wachtwoord wordt direct weggegooid en NOOIT ergens geschreven.

Wanneer je later inlogt, doen we exact hetzelfde met je ingevoerde wachtwoord en vergelijken we de resulterende hash met wat in de database staat. Match = toegang. Geen match = fout wachtwoord.

Wat gebeurt er als onze database lekt?

Laten we eerlijk zijn: dit is wat je écht wilt weten.

Stel: iemand weet onze database te stelen. Ze hebben dan een tabel met e-mails en hashed-wachtwoorden. Kunnen ze inloggen?

Kort antwoord: niet makkelijk, en voor de meeste gebruikers niet binnen redelijke tijd.

Lang antwoord: om het originele wachtwoord terug te krijgen uit een bcrypt-hash, moet een aanvaller:

  • Per wachtwoord afzonderlijk brute-forcen (door de salt is een "rainbow table" aanval onbruikbaar — elke hash is uniek zelfs bij hetzelfde wachtwoord)
  • 250ms per poging (door onze werkfactor 12)
  • Met gespecialiseerde hardware bereiken ze misschien 1000 pogingen per seconde per GPU
  • Voor een 12-tekens-wachtwoord met letters+cijfers+leestekens: ~95^12 mogelijkheden ≈ 5×10^23 — miljarden jaren op moderne GPU's

Voor zwakke wachtwoorden ("welkom123", "password1", je voornaam+geboortedatum): een brute-force kan die binnen MINUTEN kraken, zelfs met bcrypt. Dit is waarom we de minimumlengte op 12 tekens hebben gezet: elk teken extra verlengt de aanvalstijd exponentieel.

Voor gelekte wachtwoorden uit andere diensten (de meest voorkomende echte aanval): als je elders "koala1234" gebruikte en die lekte, en je gebruikte hetzelfde bij Okidoky, dan wordt "koala1234" in een wordlist gezet en tegen onze bcrypt-hashes getest. Als de aanvaller weet je e-mail, matcht dat binnen seconden — bcrypt beschermt niet tegen HERGEBRUIK van bekende wachtwoorden.

De drie vragen die je elke service zou moeten stellen

Wil je niet alleen bij Okidoky maar ook bij andere platforms de veiligheid van je wachtwoord inschatten? Stel deze drie vragen:

  1. "Gebruiken jullie bcrypt, scrypt of argon2?" — Dit zijn de drie geaccepteerde hash-functies. Als het antwoord SHA-256, MD5 of "AES-versleuteling" is, is dat een groot rood vlag. Die zijn niet ontworpen voor wachtwoord-opslag.
  2. "Wat is de minimum-lengte?" — onder 10 tekens is 2026-achterhaald. 12+ is fatsoenlijk. 16+ is voorzichtig.
  3. "Kan ik ooit mijn wachtwoord terug krijgen in plaintext?" — Als het antwoord "ja" is, is dat bewijs dat ze het NIET correct hashen. Een goed-ontworpen systeem KAN niet eens het wachtwoord lezen, alleen verifiëren of het klopt.

Wat Okidoky's antwoorden zijn

Voor volledige transparantie:

  • Hash-functie: bcrypt, werkfactor 12 (zie routes/api/auth.js in onze server-code, niet publiek maar reproducibel beschreven)
  • Minimum-lengte: 12 tekens (zie de validatie in Register.jsx, InviteRegister.jsx, ResetPassword.jsx)
  • Kan jouw wachtwoord teruggekregen worden?: nee, nooit, niemand bij ons kan dat — inclusief de eigenaar van het bedrijf. Als je 'm vergeet, doe je een reset via e-mail.
  • Wachtwoord-reset flow: we sturen een unieke, tijdelijk geldige link naar je e-mailadres (geldig 15 minuten). Via die link kies je een nieuw wachtwoord. Je oude wordt vervangen (nieuwe hash) — het originele oude wachtwoord is ook voor ons niet reconstrueerbaar.

De twee dingen die bcrypt NIET bescherming biedt

Bcrypt is sterk, maar het beschermt niet tegen:

  1. Phishing: als je je wachtwoord zelf ergens intikt op een nep-website, lacht bcrypt je niet uit. Advies: altijd de URL checken (okidoky.nl, niet ok1doky.com of een look-alike), en gebruik een password manager die alleen auto-fillt op domein-match.

  2. Wachtwoord-hergebruik: als je hetzelfde wachtwoord overal gebruikt, is één lek voldoende om toegang tot je Okidoky-account te krijgen (zie "haveibeenpwned" — het zoekt precies op dit patroon). Advies: unieke wachtwoorden per service via een password manager (Bitwarden, 1Password, KeePass).

En: 2FA lost beide gedeeltelijk op. Als je een tweede factor hebt, is alleen-wachtwoord (hoe verkregen dan ook) niet genoeg om in te loggen. Zie onze 2FA-gids voor de setup.

Waarom dit hoort saai te zijn

Wachtwoord-opslag is net zoiets als auto-motoren: als je regelmatig moet praten over de specifieke technologie, gaat er iets niet goed. Het IS een probleem waar bcrypt sinds 17 jaar het correcte antwoord op is, met een stabiele best-practice (werkfactor-aanpassen naarmate hardware sneller wordt). Vandaag op werkfactor 12. Binnen 5 jaar wordt dat werkfactor 13 of 14, en past onze code dat aan.

Als je een artikel over wachtwoord-veiligheid van een leverancier leest en het is meer dan anderhalf pagina specifieke technologie-uitleg, is er een kans dat ze iets anders proberen te verkopen dan veiligheid. Bij goede veiligheid is het vooral: kies bcrypt, zet minimum-lengte goed, doe niks geks, en herhaal dat 17 jaar.

Heb je een specifieke vraag over onze auth-flow (2FA, sessie-tijd, reset-flow)? Mail gerust security@okidoky.nl of zie onze responsible disclosure policy.