Wachtwoordbeveiliging: waarom wij elke login checken tegen datalekken.

Het probleem met wachtwoorden

Mensen zijn slecht in wachtwoorden. Dat is geen mening, dat is een feit dat keer op keer wordt bevestigd door datalekken. De meest gebruikte wachtwoorden ter wereld zijn nog steeds varianten van “123456”, “password” en “welkom01”. Maar zelfs een sterk wachtwoord is waardeloos als het al eens is gelekt bij een hack van een andere dienst.

En dat is precies waar het misgaat. Mensen hergebruiken wachtwoorden. Het wachtwoord dat jouw medewerker gebruikt voor je bedrijfsportaal, is waarschijnlijk hetzelfde wachtwoord dat hij drie jaar geleden gebruikte bij een webshop die inmiddels gehackt is. Een aanvaller hoeft dat wachtwoord alleen maar te proberen op jouw applicatie; en hij is binnen.

Dit heet credential stuffing: het systematisch proberen van eerder gelekte e-mail/wachtwoord-combinaties op andere diensten. Het is een van de meest voorkomende aanvalsmethoden en het werkt verbluffend goed.

Wat is Have I Been Pwned?

Have I Been Pwned (HIBP) is een dienst opgezet door beveiligingsonderzoeker Troy Hunt. De database bevat inmiddels meer dan 14 miljard gelekte accounts, afkomstig uit duizenden datalekken wereldwijd. Van LinkedIn en Adobe tot kleine webshops die je allang vergeten bent; als je gegevens ooit zijn gelekt, staan ze hier.

Maar HIBP biedt meer dan alleen een zoekfunctie voor eindgebruikers. De dienst heeft een API waarmee ontwikkelaars wachtwoorden kunnen controleren tegen een database van meer dan 900 miljoen unieke gelekte wachtwoorden. En het mooie: dit kan volledig privacyvriendelijk, zonder dat het wachtwoord zelf wordt verstuurd.

Hoe werkt de controle technisch?

De HIBP Pwned Passwords API werkt met een slimme techniek genaamd k-anonymity. Het wachtwoord wordt lokaal gehasht (SHA-1), en alleen de eerste vijf karakters van die hash worden naar de API gestuurd. De API stuurt een lijst terug van alle hashes die met diezelfde vijf karakters beginnen. De applicatie vergelijkt vervolgens lokaal of de volledige hash ertussen zit.

Het resultaat: je kunt controleren of een wachtwoord gelekt is, zonder dat het wachtwoord ooit in platte tekst of als volledige hash het netwerk verlaat. Privacy en veiligheid gaan hier hand in hand.

Een wachtwoord hoeft niet zwak te zijn om onveilig te zijn. Het hoeft alleen maar één keer gelekt te zijn bij een andere dienst.

Waarom wij dit standaard inbouwen

Bij Coding Agency is het controleren van wachtwoorden tegen de HIBP-database een standaard onderdeel van elke applicatie die wij bouwen met gebruikersaccounts. Niet als opt-in, niet als premium feature, maar als basisbeveiliging.

Concreet betekent dit:

• Bij registratie; Wanneer een nieuwe gebruiker een account aanmaakt, wordt het gekozen wachtwoord direct gecontroleerd. Als het voorkomt in bekende datalekken, wordt de gebruiker gevraagd een ander wachtwoord te kiezen. Niet met een cryptische foutmelding, maar met een duidelijke uitleg waarom.
• Bij wachtwoord wijzigen; Dezelfde controle vindt plaats wanneer een gebruiker zijn wachtwoord wijzigt. Zo voorkom je dat een onveilig wachtwoord via een andere route alsnog in het systeem komt.
• Bij inloggen (optioneel); In sommige applicaties controleren we ook bij het inloggen. Als een bestaand wachtwoord inmiddels in een datalek is opgedoken, krijgt de gebruiker na succesvolle login een melding om zijn wachtwoord te wijzigen.

Wat de gebruiker ziet

Beveiliging die werkt, is beveiliging die de gebruiker begrijpt. Daarom formuleren we de meldingen helder en zonder technisch jargon. Geen “SHA-1 hash collision detected”, maar iets als:

“Dit wachtwoord is eerder gevonden in een bekend datalek. Dat betekent niet dat jouw account gehackt is, maar wel dat aanvallers dit wachtwoord kennen. Kies een ander wachtwoord om je account te beschermen.”

Het doel is niet om de gebruiker bang te maken, maar om hem te helpen een veiligere keuze te maken. Transparantie en duidelijkheid zijn hier essentieel.

Laravel maakt het makkelijk

In het Laravel-ecosysteem is de integratie met HIBP bijzonder eenvoudig. Laravel biedt sinds versie 8 een ingebouwde validatieregel die wachtwoorden controleert tegen de Pwned Passwords database. Met letterlijk twee regels code voeg je deze bescherming toe aan elke formuliervalidatie.

Maar wij gaan verder dan alleen de validatieregel toepassen. We bouwen het in als onderdeel van een bredere beveiligingslaag:

• Minimale wachtwoordlengte; Minstens 10 karakters. Niet omdat het een checkbox is, maar omdat kortere wachtwoorden simpelweg sneller te kraken zijn.
• HIBP-controle; Automatische check tegen de database met gelekte wachtwoorden.
• Twee-factor authenticatie; Als extra beveiligingslaag bovenop het wachtwoord, zodat een gecompromitteerd wachtwoord niet automatisch toegang geeft.
• Bcrypt/Argon2 hashing; Wachtwoorden worden nooit in platte tekst opgeslagen. Altijd gehasht met bewezen algoritmes die specifiek zijn ontworpen om traag te zijn, zodat brute-force aanvallen onpraktisch worden.
• Rate limiting op loginpogingen; Maximaal aantal pogingen per tijdseenheid om geautomatiseerde aanvallen te blokkeren.

Beveiliging is geen feature die je aan het einde toevoegt. Het is een fundament dat je vanaf de eerste regel code meeneemt.

Meer dan alleen wachtwoorden

De HIBP-controle is slechts één onderdeel van hoe wij met authenticatie en autorisatie omgaan. We denken altijd na over het complete plaatje:

• Sessiebeveiliging; Automatisch uitloggen na inactiviteit, sessie-invalidatie bij wachtwoordwijziging, bescherming tegen session hijacking.
• Auditlogging; Elke inlogpoging, geslaagd of mislukt, wordt gelogd. Bij verdachte patronen krijgen beheerders een melding.
• Wachtwoord-reset flow; Veilige tokens met beperkte geldigheid, rate limiting op reset-aanvragen, en geen informatie lekken over welke e-mailadressen wel of niet bestaan in het systeem.
• Content Security Policy; HTTP-headers die voorkomen dat kwaadaardige scripts wachtwoorden onderscheppen via cross-site scripting.

De kosten van niet beveiligen

Een datalek is niet alleen een technisch probleem. Het is een bedrijfsprobleem. De gemiddelde kosten van een datalek in Europa lopen in de honderdduizenden euro's; en dan hebben we het nog niet over reputatieschade en het verlies van klantvertrouwen.

De AVG schrijft voor dat je “passende technische en organisatorische maatregelen” neemt om persoonsgegevens te beschermen. Wachtwoorden controleren tegen bekende datalekken valt daar nadrukkelijk onder. Het is een maatregel die minimale kosten met zich meebrengt maar maximale impact heeft op de veiligheid van je applicatie.

Het is ook een maatregel die steeds vaker wordt verwacht bij security audits en pentests. Organisaties die dit nalaten, lopen niet alleen een veiligheidsrisico maar ook een compliancerisico.

Veiligheid als standaard, niet als optie

Bij Coding Agency is wachtwoordbeveiliging geen checkbox op een offerteformulier. Het zit ingebakken in hoe wij software bouwen. Elke applicatie met gebruikersaccounts krijgt standaard een wachtwoordbeleid dat verder gaat dan “minimaal 8 tekens met een hoofdletter en een cijfer”.

We controleren wachtwoorden tegen datalekken, implementeren twee-factor authenticatie, bouwen rate limiting in, hashen met de sterkste beschikbare algoritmes en loggen alles wat relevant is voor security. Niet omdat het een verkoopargument is, maar omdat het onze verantwoordelijkheid is naar de eindgebruikers van de software die wij bouwen.

Benieuwd hoe wij de beveiliging van jouw applicatie aanpakken? Neem contact op voor een vrijblijvend gesprek.