Authenticatie Hardening
Inloggen Met Ruggengraat
Veilige webontwikkeling draait niet om extra frictie, maar om betere defaults in ontwerp, code en releaseflow.
In Authenticatie Hardening telt vooral robuuste identiteit: sterke authenticatie, betrouwbaar sessiebeheer en minimaal privilege.
Dat maakt security minder een losse controle achteraf en meer een standaardkwaliteit van je product.
Directe maatregelen (15 minuten)
Waarom dit telt
De kern van Authenticatie Hardening is risicoreductie in de praktijk. Technische context ondersteunt de maatregelkeuze, maar implementatie en borging staan centraal.
Verdediging: de complete authenticatie-checklist
Wachtwoordopslag
| Methode | Veilig? | Reden |
|---|---|---|
| Plain text | Nee | Eendatalek = alles gelekt |
| MD5 | Nee | Te snel, rainbow tables bestaan |
| SHA-256 | Nee | Te snel, geen salt |
| SHA-256 + salt | Matig | Beter, maar nog steeds te snel |
| bcrypt (cost 10+) | Ja | Opzettelijk langzaam, ingebouwde salt |
| Argon2id | Ja | Winnaar Password Hashing Competition; memory-hard |
| scrypt | Ja | Memory-hard, CPU-hard |
De juiste keuze in 2026 is Argon2id of bcrypt. Alles anders is een bevinding.
Wachtwoordbeleid
Het NIST-advies (SP 800-63B) is verhelderend:
- Minimaal 8 tekens (liever 12+)
- Geen verplichte complexiteitsregels (hoofdletters, cijfers, symbolen)
- Geen verplichte periodieke wijzigingen
- Check tegen breached password databases (HaveIBeenPwned)
- Blokkeer de meest voorkomende wachtwoorden
Ja, je leest dat goed. NIST raadt af om complexiteitsregels en periodieke wijzigingen te verplichten. De reden: deze regels leiden tot voorspelbare patronen (seizoen + jaar + uitroepteken) die zwakker zijn dan een zelfgekozen, lang wachtwoord.
Rate limiting en lockout
# Voorbeeld: progressieve vertraging
DELAY_MAP = {
3: 5, # Na 3 pogingen: 5 seconden wachten
5: 30, # Na 5 pogingen: 30 seconden
10: 300, # Na 10 pogingen: 5 minuten
20: 3600, # Na 20 pogingen: 1 uur
}Implementeer rate limiting op meerdere niveaus: - Per account - Per IP-adres - Per sessie - Globaal (als noodrem)
Multi-factor authenticatie
MFA is de enige verdediging die standhoudt als het wachtwoord is gecompromitteerd. Prioriteit:
- Hardware keys (YubiKey, FIDO2): beste optie, phishing-resistent
- Authenticator apps (TOTP): goed, maar phishable
- SMS/e-mail codes: beter dan niets, maar kwetsbaar voor SIM-swap/account-takeover
Laten we hier even opmerken dat we collectief al meer dan dertig jaar weten hoe wachtwoorden veilig moeten worden opgeslagen. Bcrypt bestaat sinds 1999. Dat is meer dan een kwart eeuw. In die tijd hebben we de iPhone uitgevonden, auto’s die zelf rijden, en een robot op Mars gezet. Maar wachtwoorden hashen met bcrypt – dat is blijkbaar een brug te ver voor sommige ontwikkelaars.
En dan het wachtwoordbeleid. We dwingen mensen om elke negentig dagen hun wachtwoord te wijzigen, wat resulteert in “Zomer2026!”, en vervolgens zijn we verbaasd dat iemand dat raadt. Dat is alsof je iemand dwingt om elke drie maanden een nieuw slot op zijn voordeur te zetten, maar alleen sloten verkoopt met drie mogelijke combinaties.
Het alternatief – een lang, uniek wachtwoord dat je nooit hoeft te wijzigen, opgeslagen in een password manager – is te simpel. Te elegant. Waar blijft de complexiteit? Waar blijft het lijden? Want als beveiliging niet pijnlijk is, dan voelt het niet alsof het werkt. En dat, dames en heren, is waarom we nog steeds “Welkom01!” als wachtwoord tegenkomen in Fortune 500-bedrijven.
Samenvatting
Authenticatie is het fundament van elk beveiligingssysteem. Brute force is de meest directe aanval erop – inelegant maar effectief, vooral wanneer gebruikers voorspelbare wachtwoorden kiezen. Password spraying exploiteert het feit dat in elke grote organisatie iemand het voor de hand liggende wachtwoord heeft gekozen. En woordlijsten, op maat gemaakt met website-scraping en mutatieregels, zijn het verschil tussen uren tevergeefs draaien en een hit binnen minuten.
Sessiemanagement – session tokens, cookies, JWTs – is het mechanisme waarmee we authenticatie onthouden over stateless HTTP. Zwakke tokens, ontbrekende cookie-flags, en kwetsbare JWT-implementaties ondermijnen elk sterk wachtwoordbeleid.
De verdediging is niet revolutionair: bcrypt of Argon2 voor wachtwoordopslag, MFA voor een tweede factor, rate limiting tegen brute force, en security headers als eerste verdedigingslinie. Het zijn dingen die we al jaren weten. De vraag is niet of we weten hoe we authenticatie moeten beveiligen. De vraag is waarom we het nog steeds niet doen.
In het volgende hoofdstuk brengen we alles samen: findings documenteren, CVSS 4.0 scoren, en rapporten genereren die ervoor zorgen dat al deze kwetsbaarheden daadwerkelijk worden opgelost.
Verder lezen in de kennisbank
Deze artikelen in het portaal geven je meer achtergrond en praktische context:
- API's — de onzichtbare lijm van het internet
- SSL/TLS — waarom dat slotje in je browser ertoe doet
- Encryptie — de kunst van het onleesbaar maken
- Wachtwoord-hashing — hoe websites je wachtwoord opslaan
- Penetratietesten vs. vulnerability scans
Je hebt een account nodig om de kennisbank te openen. Inloggen of registreren.
Gerelateerde securitymaatregelen
Deze artikelen bieden aanvullende context en verdieping: