Module 7 · 7.3
Nederlands
Inloggen: wachtwoorden, tweestapsverificatie en brute force
Module 7: Beveiliging · Leestijd: 9 minuten
Leerdoel: Na deze les kun je het inloggen op je site afschermen met sterke wachtwoorden, tweestapsverificatie en het beperken van inlogpogingen, en weet je wat xmlrpc.php is.
Kernbegrippen: wachtwoordmanager, wachtzin, uniek wachtwoord, tweestapsverificatie (2FA, TOTP), passkey, brute force, inlogpogingen beperken, wp-login.php op IP-adres, xmlrpc.php, gebruikersnamen die uitlekken (REST, ?author=), applicatiewachtwoorden
Het wachtwoord: lang en uniek
Een goed wachtwoord heeft twee eigenschappen:
- Lang: lengte telt meer dan vreemde tekens. Een wachtzin van vier of vijf willekeurige woorden (
zeef-pinguin-oktober-lantaarn) is sterker en beter te onthouden danW8w00rd!. De overheidscampagne Veilig Internetten adviseert een uniek wachtwoord van minimaal 12 tekens, bij voorkeur een wachtwoordzin. - Uniek: nergens anders gebruikt. Credential stuffing (les 7.1) werkt alleen als je een wachtwoord hergebruikt.
Niemand onthoudt tientallen lange unieke wachtwoorden. Gebruik daarom een wachtwoordmanager: een programma dat ze voor je maakt, bewaart en invult. Dan hoef je er maar één te onthouden: dat van de manager zelf, en dat beveilig je ook met tweestapsverificatie.
Of een wachtwoord in een bekend datalek zit, kun je nagaan op haveibeenpwned.com. Staat je e-mailadres in een lek, verander dan het wachtwoord bij elke dienst waar je datzelfde wachtwoord gebruikte.
Tweestapsverificatie
Met tweestapsverificatie (2FA) heb je bij het inloggen naast je wachtwoord nog iets nodig: meestal een code van zes cijfers uit een app op je telefoon (een authenticator, volgens de standaard TOTP). Een inbreker met je wachtwoord komt dan nog niet binnen.
WordPress heeft geen ingebouwde tweestapsverificatie. Je voegt het toe met een plugin. Er zijn er veel; een eenvoudige is Two Factor, gemaakt door bijdragers aan WordPress zelf. Ook beveiligingsplugins hebben het vaak aan boord. Let bij het kiezen op:
- TOTP-apps en back-upcodes (voor als je telefoon kwijt is); codes per e-mail zijn zwakker, omdat je mailbox ook gehackt kan worden;
- verplicht kunnen stellen voor beheerders en redacteuren;
- passkeys: inloggen met je vingerafdruk, gezicht of een beveiligingssleutel, zonder wachtwoord. Daar zijn ook plugins voor. Passkeys zijn bestand tegen phishing, omdat ze alleen werken op de echte site.
Zet tweestapsverificatie ook aan op alles wat om je site heen zit: je hostingpaneel, je e-mail, je registrar en je wachtwoordmanager. Een inbreker die je hostingpaneel overneemt, heeft je WordPress-wachtwoord niet nodig.
Brute force en inlogpogingen beperken
Een open WordPress-site krijgt de hele dag inlogpogingen op wp-login.php, vaak met admin en lijsten veelgebruikte wachtwoorden. Met een lang wachtwoord en 2FA komen ze niet binnen, maar elke poging kost je server rekenwerk (een volledige WordPress-start). Bij een grote golf wordt je site traag.
WordPress zelf beperkt het aantal pogingen niet. Wat helpt, in volgorde van "vroeg tegenhouden":
- Op de server: veel hosters blokkeren een IP-adres dat in korte tijd veel mislukte pogingen doet, nog voordat WordPress start (met een firewall of een webserverfunctie). Vraag je hoster wat er gebeurt.
- wp-login.php alleen voor jouw IP-adres: met een paar regels in
.htaccess(bij LiteSpeed en Apache):
<Files wp-login.php>
Require ip 192.0.2.10
</Files>Dat werkt goed als je een vast IP-adres hebt. Heb je dat niet (thuis, op je telefoon), dan sluit je jezelf af als je adres verandert. Een alternatief is een extra wachtwoord op de inlogpagina (een "beveiligde map", basic authentication) met een ander wachtwoord dan je WordPress-wachtwoord.
- Een plugin die pogingen beperkt: na vijf mislukte pogingen is het IP-adres een tijd geblokkeerd. Werkt, maar pas als WordPress al draait, dus het rekenwerk blijft.
Het verbergen of hernoemen van de inlogpagina (bijvoorbeeld /mijn-login in plaats van /wp-login.php) vermindert de ruis in je logboek. Het is geen echte beveiliging, en sommige plugins en thema's verwachten het standaardadres. Prima als extra, nooit in plaats van een goed wachtwoord en 2FA.
xmlrpc.php
xmlrpc.php is een oude koppeling uit de tijd vóór de REST API, waarmee apps en andere sites met WordPress praten. Hij wordt nog gebruikt door sommige apps, door Jetpack en door een paar koppelingen. Voor de meeste sites is hij overbodig.
Inbrekers houden van xmlrpc.php, omdat je er in één verzoek honderden wachtwoorden tegelijk kunt proberen (met de functie system.multicall), en omdat hij voor aanvallen op andere sites misbruikt kan worden (pingbacks). Wat je doet:
- Gebruik je hem niet: blokkeer hem. Sommige hosters, waaronder WebOké, blokkeren xmlrpc.php standaard op de server. Anders met een regel in
.htaccessof met een beveiligingsplugin. - Gebruik je hem wel (bijvoorbeeld voor een app die het nodig heeft): laat hem open, maar zorg voor sterke wachtwoorden, 2FA en een beperking van pogingen. Moderne apps gebruiken meestal de REST API met een applicatiewachtwoord (les 3.3).
Gebruikersnamen die uitlekken
In les 3.3 zag je dat WordPress een afgeleide van gebruikersnamen laat zien:
https://example.com/?author=1stuurt door naar/author/<naam>/;https://example.com/wp-json/wp/v2/userstoont een lijst met de slugs van iedereen die iets heeft gepubliceerd.
Is dat erg? Een gebruikersnaam is geen wachtwoord. Met een lang uniek wachtwoord en 2FA maakt het weinig uit. Maar het geeft een inbreker de helft van de inloggegevens en maakt gerichte phishing makkelijker. Redelijke maatregelen:
- geef beheerders een gebruikersnaam die niet hun publieke naam is, en publiceer niet met een beheerdersaccount (les 3.3);
- beperk de gebruikerslijst in de REST API met een beveiligingsplugin of een paar regels code, als je hem niet nodig hebt. Zet de REST API niet helemaal dicht: de blokeditor en veel plugins hebben hem nodig.
Applicatiewachtwoorden
Applicatiewachtwoorden (les 3.3) zijn een veilige manier om een app of systeem toegang te geven, maar ze omzeilen je tweestapsverificatie: een app met een applicatiewachtwoord heeft geen code nodig. Maak ze alleen aan als het moet, bij een account met een lage rol, en trek ze in als je de koppeling niet meer gebruikt.
Samenvatting
- Gebruik lange, unieke wachtwoorden (wachtzinnen) in een wachtwoordmanager.
- Zet tweestapsverificatie aan, met een plugin in WordPress en ook op je hostingpaneel, mail en registrar.
- Houd inlogpogingen zo vroeg mogelijk tegen: op de server, met een IP-regel of extra wachtwoord, of met een plugin.
- Blokkeer xmlrpc.php als je hem niet gebruikt.
- Uitgelekte gebruikersnamen zijn geen ramp, wel een hint: publiceer niet als beheerder en beperk de REST-gebruikerslijst als je hem niet nodig hebt.
Quiz
Opdracht
Opdracht A7.3: Wat laat je site prijs bij het inloggen? Vul het adres van je site in en bewijs dat het je eigen site is (met de code van de opdracht, als TXT-record of als bestand). Het programma controleert drie dingen: of xmlrpc.php een lijst met functies teruggeeft (open) of geblokkeerd is, of /wp-json/wp/v2/users gebruikersnamen (slugs) toont, en waar /?author=1 naartoe doorstuurt. Vul in of je xmlrpc.php nodig hebt; zo niet, dan is een open xmlrpc.php rood. Uitgelekte slugs zijn oranje met uitleg.
Opdracht D7.3: Tweestapsverificatie aanzetten. Zet tweestapsverificatie aan voor alle beheerders van je WordPress-site, en ook op je hostingpaneel en je e-mail. Bewaar de back-upcodes in je wachtwoordmanager. Vink per onderdeel aan dat het aan staat en noteer welke methode je gebruikt (app, passkey, e-mail) en waar de back-upcodes staan. Noteer ook hoe je wp-login.php extra beschermt en waarom je voor die manier kiest.
Opdracht D7.3: Tweestapsverificatie aanzetten
Deze opdracht doe je zelf; niemand kijkt hem na. Vink af wat je gedaan hebt en markeer de opdracht als gedaan.
Gebruik bij beheerders liever een app of passkey dan alleen e-mail. Een vast IP-adres kun je toelaten op wp-login.php; met wisselende adressen past beperking van inlogpogingen beter.
Je vinkjes en aantekeningen blijven alleen in deze browser; we sturen ze nergens heen. Ben je aangemeld, dan bewaren we in Mijn cursussen alleen dat je de opdracht gedaan hebt.
Verder lezen
Deze artikelen beschrijven de stappen in de panelen van WebOké; in andere panelen werken ze vergelijkbaar.
- DirectAdmin handleiding 3.7: Veilige wachtwoorden en wat je doet bij een gelekt wachtwoord
- Tweestapsverificatie in Mijn WebOké en een authenticator-app instellen
- WordPress: toegang tot xmlrpc.php lukt niet
- wp-login.php van WordPress beveiligen
- DirectAdmin handleiding 15.9: Met een wachtwoord beveiligde mappen
- Veilig inloggen (Veilig Internetten, overheid): https://veiliginternetten.nl/veilig-inloggen/
- Brute force-aanvallen (developer.wordpress.org, Engels): https://developer.wordpress.org/advanced-administration/security/brute-force/
