Zwakke eisen aan wachtwoorden

Weinig beveiligingsonderwerpen zijn de afgelopen jaren zo grondig van inzicht veranderd als het wachtwoordbeleid. De regels waarmee de meeste applicaties nog werken (minimaal acht tekens, een hoofdletter, een cijfer, elk kwartaal wijzigen) worden door de huidige richtlijnen niet alleen als achterhaald maar als schadelijk beschouwd. Hieronder leest u wat er in de plaats komt en waarom.

Wat zijn zwakke wachtwoordeisen?

Zwakke eisen aan wachtwoorden zijn regels die onvoldoende voorkomen dat gebruikers een wachtwoord kiezen dat eenvoudig te raden of al bekend is uit eerdere datalekken. In de praktijk gaat het meestal om een te lage minimumlengte, het ontbreken van een controle op bekende gelekte wachtwoorden, of het toestaan van wachtwoorden die gelijk zijn aan de gebruikersnaam of de bedrijfsnaam.

Tegelijk zit er een minder voor de hand liggende kant aan. Regels die complexiteit afdwingen (minstens één hoofdletter, één cijfer, één leesteken) verhogen de veiligheid nauwelijks en verlagen die soms zelfs. Mensen reageren op zulke eisen met voorspelbare patronen: Welkom2026! voldoet aan elke complexiteitsregel en staat in elke woordenlijst die een aanvaller gebruikt.

De vergelijking gaat op met een slot waarbij de eigenaar wordt verplicht een sleutel met een bepaald aantal groeven te kiezen. Het aantal theoretische mogelijkheden neemt toe, maar omdat iedereen dezelfde vorm kiest, hoeft de inbreker maar een handvol sleutels te proberen. Wat telt is niet hoe ingewikkeld het wachtwoord eruitziet, maar hoe onvoorspelbaar het werkelijk is.

Hoe ziet een verstandig beleid eruit?

Kwetsbaar:

function wachtwoordIsGeldig(wachtwoord) {
  return wachtwoord.length >= 8
    && /[A-Z]/.test(wachtwoord)
    && /[a-z]/.test(wachtwoord)
    && /[0-9]/.test(wachtwoord)
    && wachtwoord.length <= 16;        // en niet langer
}

Deze controle keurt Zomer24! goed en weigert de kat sprong over de blauwe schutting. Dat is precies verkeerd om: het eerste staat in vrijwel elke lijst met veelgebruikte wachtwoorden, terwijl het tweede aanzienlijk meer entropie heeft. De maximumlengte van zestien tekens is bovendien een slecht teken, want bij een correct gehasht wachtwoord bestaat er geen reden om de lengte zo streng te beperken.

Veilig:

async function wachtwoordIsGeldig(wachtwoord, gebruiker) {
  if (wachtwoord.length < 12 || wachtwoord.length > 128) return false;

  // Geen wachtwoord dat afgeleid is van de eigen gegevens
  const eigen = [gebruiker.email.split('@')[0], gebruiker.naam, 'assistsec'];
  const klein = wachtwoord.toLowerCase();
  if (eigen.some((t) => t && klein.includes(t.toLowerCase()))) return false;

  // Bekend uit eerdere datalekken of veelgebruikt
  if (await staatOpBlokkadelijst(wachtwoord)) return false;

  return true;
}

// Controle met k-anonimiteit: het wachtwoord verlaat uw omgeving nooit
async function staatOpBlokkadelijst(wachtwoord) {
  const hash = sha1(wachtwoord).toUpperCase();
  const antwoord = await fetch(`https://api.pwnedpasswords.com/range/${hash.slice(0, 5)}`);
  const staart = hash.slice(5);
  return (await antwoord.text()).split('\n').some((r) => r.startsWith(staart));
}

Het accent is verschoven. De minimumlengte gaat omhoog naar twaalf tekens, de maximumlengte is ruim genoeg om wachtwoordzinnen toe te laten, en er zijn geen complexiteitsregels meer die patronen uitlokken. In plaats daarvan wordt gecontroleerd wat er werkelijk toe doet: is dit wachtwoord al eens gelekt, en is het herleidbaar tot de gebruiker zelf? Bij de controle op de blokkadelijst worden alleen de eerste vijf tekens van de hash verstuurd, zodat het wachtwoord zelf uw omgeving niet verlaat.

Wat is de impact van een zwak wachtwoordbeleid?

De ernst blijft doorgaans laag tot middelzwaar, omdat een zwak beleid op zichzelf geen toegang geeft. Het bepaalt hoe waarschijnlijk het is dat een aanval op de authenticatie slaagt.

Twee aanvalsvormen profiteren er direct van. Bij password spraying probeert een aanvaller één veelgebruikt wachtwoord op veel accounts; hoe meer gebruikers een voorspelbaar wachtwoord mochten kiezen, hoe groter de kans dat er één raak is. Bij credential stuffing worden combinaties uit eerdere datalekken hergebruikt; ontbreekt een blokkadelijst, dan kan een gebruiker precies het wachtwoord kiezen dat elders al is gelekt.

Wat het risico vergroot is dat een geslaagde aanval hier volledige toegang oplevert, met alle rechten van het account en zonder dat er iets ongewoons in de logbestanden hoeft te staan. Betreft het een beheerdersaccount, dan is de impact op het hele systeem. En omdat mensen wachtwoorden hergebruiken tussen diensten, raakt een lek bij u ook accounts elders, wat naast een beveiligingsprobleem een reputatiekwestie is.

Hoe spoor je een zwak wachtwoordbeleid op?

Een tester probeert bij het registreren en bij het wijzigen van een wachtwoord welke waarden worden geaccepteerd. Wordt een wachtwoord van acht tekens toegelaten? Kan Welkom2026! worden gekozen? En de gebruikersnaam zelf, of de naam van de organisatie? Dat geeft snel een beeld van de werkelijke ondergrens.

Vervolgens wordt gekeken of de regels aan serverzijde worden afgedwongen of alleen in de browser. Een controle die uitsluitend in JavaScript staat, is met één rechtstreeks verzoek te omzeilen: een veelvoorkomende bevinding. Ook wordt getest of de eisen gelijk zijn bij registratie, bij wachtwoordherstel en bij het wijzigen vanuit het profiel, want die drie routes zijn vaak apart geïmplementeerd en verschillen dan in strengheid. Verder wordt beoordeeld of er een blokkadelijst wordt gehanteerd, of plakken is toegestaan en of er een maximumlengte is die op een implementatieprobleem wijst. AssistSec beoordeelt het beleid altijd samen met de aanwezigheid van een tweede factor en van beperkingen op inlogpogingen, omdat die drie gezamenlijk bepalen hoe weerbaar de authenticatie werkelijk is.

Hoe voorkom je een zwak wachtwoordbeleid?

• Stel een minimumlengte van ten minste twaalf tekens in, en voor beheerdersaccounts liefst meer.
• Laat complexiteitsregels los; ze leiden tot voorspelbare patronen zonder werkelijke winst.
• Controleer elk nieuw wachtwoord tegen een blokkadelijst van gelekte en veelgebruikte wachtwoorden.
• Weiger wachtwoorden die zijn afgeleid van de gebruikersnaam, het e-mailadres of de naam van uw organisatie.
• Sta een ruime maximumlengte toe (64 tot 128 tekens) en accepteer spaties en alle bijzondere tekens.
• Sta plakken toe, zodat wachtwoordmanagers bruikbaar blijven.
• Dwing periodieke wijziging niet af; vraag alleen om een nieuw wachtwoord bij een concrete aanwijzing van compromittering.
• Handhaaf alle regels aan serverzijde, niet alleen in de browser, en op alle routes waar een wachtwoord wordt gekozen.
• Combineer het beleid met tweefactorauthenticatie en met een limiet op inlogpogingen.