Wachtwoordbeveiliging in WordPress: waarom je wachtwoord het grootste risico is
De meeste gehackte WordPress-sites sneuvelen niet door een ontbrekende beveiligingsplugin, maar door zwakke wachtwoorden van gebruikers. Waarom lengte zwaarder weegt dan acrobatiek met leestekens, welke mythes je mag laten vallen en hoe je sterke wachtwoorden bouwt die blijven hangen.
Als een WordPress-site gehackt wordt, valt de verdenking uit reflex op ontbrekende techniek: geen beveiligingsplugin, geen firewall, geen malwarescanner. De ongemakkelijke waarheid ziet er anders uit. In de praktijk is de grootste zwakke plek van bijna elke WordPress-site veel banaler: zwakke, hergebruikte of raadbare wachtwoorden van gebruikers. Een aanvaller die met geldige inloggegevens binnenkomt, laat geen enkel firewallalarm afgaan. Hij is gewoon binnen.
Dit artikel legt uit waarom wachtwoorden de belangrijkste ingang zijn, ruimt op met de hardnekkigste wachtwoordmythes en laat een methode zien waarmee je echt sterke wachtwoorden bouwt die je toch kunt onthouden. En omdat het onderwerp zwaar weegt, werkt het recept zonder enig hulpmiddel.
Waarom wachtwoorden de belangrijkste ingang zijn
WordPress-logins worden niet aangevallen door verveelde eenlingen, maar door botnets die de klok rond geautomatiseerd werken. Twee aanvalspatronen overheersen:
Brute force en woordenboekaanvallen: bots proberen systematisch miljoenen combinaties, te beginnen bij klassiekers als 123456, wachtwoord of de naam van de site plus een jaartal. Korte of voor de hand liggende wachtwoorden vallen niet in weken maar in seconden tot minuten. Favoriete doelen zijn wp-login.php en de vaak vergeten interface xmlrpc.php: via de functie system.multicall daarvan zijn honderden wachtwoordpogingen in één verzoek te verpakken, waarmee klassieke inloglimieten elegant omzeild worden. Heb je XML-RPC niet nodig, bijvoorbeeld voor de Jetpack-koppeling of oude app-verbindingen, zet die interface dan uit.
Credential stuffing: nog efficiënter is helemaal niet raden. Uit datalekken bij andere diensten circuleren miljarden echte combinaties van e-mailadres en wachtwoord. Bots proberen die lijsten gewoon op WordPress-logins. Wie hetzelfde wachtwoord gebruikt voor de webshop, het e-mailaccount en de WordPress-beheeromgeving, is na het volgende lek bij een van die diensten overal tegelijk gecompromitteerd. Hergebruik van wachtwoorden is dus geen schoonheidsfoutje, maar de directe draad van andermans datalek naar jouw beheeromgeving.
Een beveiligingsplugin kan veel van die pogingen onderscheppen en vertragen, en dat is waardevol. Maar tegen een geldig, gestolen of geraden wachtwoord helpt geen enkele firewall ter wereld. Daarom komt wachtwoordhygiëne vóór elke pluginkeuze.
De drie grootste wachtwoordmythes
Rond wachtwoorden houden zich regels staande die twintig jaar geleden goed bedoeld waren en vandaag aantoonbaar meer schaden dan helpen. Ook het Amerikaanse NIST en het Duitse BSI hebben hun aanbevelingen omgezet.
Mythe 1: een wirwar van leestekens verslaat lengte
Het korte P@ssw0rd! oogt veilig maar is het niet: precies deze vervangingen (a naar @, o naar 0, uitroepteken aan het eind) horen allang bij elke woordenboekaanval. Een wachtwoord met acht cryptische tekens is rekenkundig veel zwakker dan een wachtwoord met twintig eenvoudige. Lengte verslaat complexiteit, en niet nipt maar met ordes van grootte. Elk extra teken vermenigvuldigt de moeite voor de aanvaller in plaats van er alleen bij op te tellen.
Mythe 2: wachtwoorden moeten regelmatig gewisseld worden
Gedwongen wissels om de 90 dagen leiden in de praktijk tot een voorspelbaar patroon: van Zomer2025! wordt Herfst2025!. Zulke rotaties verlagen de werkelijke veiligheid, omdat mensen onthoudbare systemen bouwen die aanvallers net zo goed kennen. De moderne aanbeveling luidt: een sterk wachtwoord blijft staan tot er een concrete aanleiding is, bijvoorbeeld een datalek bij de dienst of het vermoeden dat iemand heeft meegelezen. Dan wordt er meteen gewisseld, niet volgens de kalender.
Mythe 3: "mijn blog is te klein om aangevallen te worden"
Bots kennen geen bereik. Ze scannen IP-reeksen en domeinlijsten compleet af, en een kleine tuinblog is voor hen net zo interessant als een groot magazine: als spamverspreider, phishinghost, linkfarm voor zoekmachines of springplank voor verdere aanvallen. De vraag is niet of je inlogpagina geautomatiseerd wordt aangevallen. Dat gebeurt al, waarschijnlijk meermaals per dag. De enige vraag is of die pogingen in het niets lopen.
Wat wel helpt: lengte, willekeur, uniciteit
De sterkte van een wachtwoord laat zich in één begrip vatten: entropie, oftewel de hoeveelheid echte willekeur die erin zit. Eenvoudig gezegd: hoeveel mogelijkheden moet een aanvaller aflopen tot hij je wachtwoord zeker gevonden heeft? Elk extra willekeurig teken vermenigvuldigt dat aantal. Een willekeurig wachtwoord van 12 tekens uit letters, cijfers en leestekens biedt al meer combinaties dan alle computers ter wereld in eeuwen kunnen proberen, en een van 16 tot 20 tekens is op afzienbare termijn praktisch niet te kraken.
Het beslissende woord is willekeurig. Het begin van een songtekst van 20 tekens is niet willekeurig, dat staat in dezelfde lijsten als de woordenboeken. Daaruit volgen drie eenvoudige regels:
1. Lengte: minstens 16 tekens, liever meer. 2. Willekeur: de bouwstenen moeten geloot worden en niet bedacht, want mensen zijn beroerde willekeursgeneratoren. 3. Uniciteit: elke dienst krijgt zijn eigen wachtwoord, zodat een lek bij dienst A dienst B niet opent. Wie alle drie de regels aanhoudt, heeft het wachtwoordprobleem in de kern opgelost. Blijft één vraag over: hoe onthoud je zoiets?
De verhaalmethode: wachtwoorden uit beelden
Ons brein is slecht in tekensalade en uitstekend in beelden en verhalen. Precies dat gebruikt de verhaalmethode: in plaats van E3nh00rn!Id33#B4dku1p-4711 als tekenreeks te onthouden, onthoud je een absurd beeld: "De eenhoorn heeft een idee in de badkuip" 🦄💡🛁. Uit die zin wordt het wachtwoord volgens vaste, eenvoudige regels afgeleid: de opvallende woorden overnemen, een paar letters door cijfers vervangen, scheidingstekens en een getal toevoegen. Het beeld is zo raar dat het blijft hangen, en het afgeleide wachtwoord is lang, gemengd en komt in geen enkel woordenboek voor.
De adder onder het gras bij zelfbedachte zinnen: mensen bedenken voorspelbare zinnen. Daarom moet het verhaal geloot worden, niet gekozen.
Belangrijk om goed te plaatsen: de verhaalmethode is bedoeld voor de paar wachtwoorden die je echt in je hoofd moet hebben. Voor alle andere is er een betere oplossing, daarover zo meteen meer. Een uitgebreidere handleiding bij de methode zelf, inclusief rekenvoorbeeld, staat in ons artikel Veilig wachtwoord maken.
Concrete maatregelen voor WordPress-beheerders
Een sterk eigen wachtwoord is het halve werk. De andere helft: ervoor zorgen dat ook alle andere accounts op je site geen ingang vormen. Deze vijf maatregelen dekken de praktijk:
1. Streng wachtwoordbeleid voor alle rollen
Het sterkste beheerderswachtwoord helpt weinig als een redactieaccount met zomer123 beveiligd is. Ook accounts met minder rechten zijn waardevolle buit, bijvoorbeeld voor spamcontent of als startpunt voor rechtenuitbreiding. WordPress toont bij de wachtwoordkeuze een sterktemeter, maar laat zwakke wachtwoorden na bevestiging alsnog toe. Een afgedwongen minimumsterkte voor alle rollen, via plugin of teamafspraak, dicht dat gat. Bijzondere verantwoordelijkheid draagt wie een ledengedeelte beheert: daar hangen snel honderden of duizenden gebruikersaccounts aan je site, en die inloggegevens bescherm je mee. Wie zoiets plant of beheert, kiest beter een oplossing die beveiliging van meet af aan meedenkt, zoals onze MemberJet met security by design. Wat de betaalde versies kosten staat op het prijsoverzicht, en de gratis versie blijft gratis.
2. Tweefactorauthenticatie aanzetten
Een tweede factor (authenticator-app of beveiligingssleutel) maakt een gestolen wachtwoord op zichzelf waardeloos. Voor beheerders- en redactieaccounts hoort tweefactorauthenticatie verplicht te zijn, geen optie. Het instellen kost een paar minuten per account en is verreweg de effectiefste aanvulling op een sterk wachtwoord.
3. Inlogpogingen begrenzen
Standaard staat WordPress onbeperkt veel inlogpogingen toe, een cadeau aan elke brute-force-bot. Een limiet met een blokkade of wachttijd erna remt geautomatiseerde aanvallen fors af. Veel gangbare beveiligingsplugins brengen die functie mee, en zoals hierboven beschreven hoort xmlrpc.php in de begrenzing mee, anders loopt de aanval gewoon via de achterdeur door.
4. Applicatiewachtwoorden in plaats van je hoofdwachtwoord voor API's
Wanneer externe diensten, apps of scripts via de REST API bij je site komen, hoort je hoofdwachtwoord daar niet thuis. WordPress heeft sinds versie 5.6 applicatiewachtwoorden: eigen, willekeurig gegenereerde toegangscodes per toepassing die je afzonderlijk kunt intrekken zonder je echte wachtwoord te wijzigen. Lekt een dienst zo'n code, dan trek je precies die ene in en de rest blijft onaangeroerd.
5. Geen gebruikersnaam "admin"
De gebruikersnaam is de halve toegangscombinatie, en admin is de eerste helft die elke bot probeert. Een eigen gebruikersnaam is op zichzelf geen sterke bescherming, maar zeeft de domste 90 procent van de geautomatiseerde pogingen vooraf weg. Loopt je beheerdersaccount nog op admin: nieuw account met eigen naam aanmaken, rechten overdragen, oud account verwijderen.
Voor al het andere: de wachtwoordmanager
De verhaalmethode is bewust bedoeld voor weinig wachtwoorden: de twee of drie die je nergens kunt opzoeken, dus het hoofdwachtwoord van je wachtwoordmanager en de login van je apparaten. Voor alle andere accounts is de wachtwoordmanager de standaardaanbeveling, zonder mitsen en maren: hij maakt voor elke dienst een lang, willekeurig, uniek wachtwoord en onthoudt het voor je. Daarmee is de regel van uniciteit vanzelf vervuld en loopt credential stuffing bij jou in het niets.
De taakverdeling is dus eenvoudig: een sterk hoofdwachtwoord volgens de verhaalmethode beschermt de wachtwoordmanager, de wachtwoordmanager beschermt al het andere, en tweefactorauthenticatie beveiligt de belangrijkste accounts extra. Wie die drie bouwstenen combineert, heeft meer gedaan voor de veiligheid van zijn WordPress-site dan met welke goed ingestelde beveiligingsplugin ook alleen.
Een ledengedeelte met beveiliging vanaf het begin
Wie gebruikersaccounts beheert, beschermt ook de inloggegevens van anderen. MemberJet brengt toegangsniveaus, cursusstructuur en de Digistore24-koppeling mee, zonder omzetdeling en zonder transactiekosten.
Veelgestelde vragen
Hoe lang moet een veilig WordPress-wachtwoord zijn?
Minstens 16 tekens, liever meer. Naast de lengte is doorslaggevend dat het wachtwoord willekeurig is samengesteld en bij geen enkele andere dienst in gebruik is. Een lang, willekeurig wachtwoord van 16 tot 20 tekens is met de huidige techniek praktisch niet door proberen te kraken, terwijl een kort wachtwoord met vervangingen als "P@ssw0rd!" in seconden valt, omdat precies die patronen bij elke woordenboekaanval horen.
Moet ik mijn WordPress-wachtwoord regelmatig wijzigen?
Nee, gedwongen wissels volgens de kalender gelden tegenwoordig als contraproductief, omdat ze tot voorspelbare patronen leiden zoals "Zomer2025!" dat "Herfst2025!" wordt. Zowel het NIST als het Duitse BSI adviseren inmiddels: een sterk, uniek wachtwoord blijft staan tot er een concrete aanleiding is, bijvoorbeeld een bekend geworden datalek of het vermoeden van misbruik. Dan moet het meteen gewijzigd worden, niet pas op de volgende peildatum.
Lost een beveiligingsplugin het wachtwoordprobleem niet op?
Niet in zijn eentje. Een beveiligingsplugin onderschept en vertraagt veel geautomatiseerde pogingen, en het begrenzen van inlogpogingen hoort bij de goede praktijk. Maar tegen een geldig, gestolen of geraden wachtwoord helpt geen firewall: wie met kloppende inloggegevens binnenkomt, laat geen alarm afgaan. Daarom komt wachtwoordhygiëne vóór de pluginkeuze, niet erna.
