Direct naar de inhoud

Cookie-instellingen

Kies per soort welke cookies je toestaat. Je kunt je keuze altijd wijzigen via Cookie-instellingen onderaan elke pagina. Privacyverklaring

Noodzakelijk

Altijd aan

Nodig om in te loggen, je winkelwagen te bewaren en je keuzes te onthouden. Deze staan altijd aan.

Welke cookies?
  • weboke_sessie, weboke_klant, weboke_remember: je sessie en ingelogd blijven
  • weboke_basket: je winkelwagen
  • wkBtwIncl: prijzen met of zonder btw tonen
  • wok_cookies: je cookiekeuze, 12 maanden

Meet welke advertentie tot een bezoek of bestelling leidt, zodat we niet betalen voor advertenties die niets doen.

Welke cookies?
  • Google Ads via Google Tag Manager (_gcl_au, _gcl_aw), tot 90 dagen
  • OpenAI Ads, advertenties in ChatGPT
  • wok_aff: via welke partner je bij ons kwam (affiliateprogramma), 60 dagen

4,6

Land en taal

Elk land heeft zijn eigen site, met prijzen en btw van dat land.

Bekijken

Module 7 · 7.3

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:

  1. 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 dan W8w00rd!. De overheidscampagne Veilig Internetten adviseert een uniek wachtwoord van minimaal 12 tekens, bij voorkeur een wachtwoordzin.
  2. 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":

  1. 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.
  2. 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.

  1. 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 .htaccess of 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=1 stuurt door naar /author/<naam>/;
  • https://example.com/wp-json/wp/v2/users toont 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

1. Welk wachtwoord is het sterkst?



2. Waarom is xmlrpc.php populair bij inbrekers?



3. Je zet wp-login.php vast op het IP-adres van je kantoor. Wat is het risico?



4. Is het hernoemen van de inlogpagina naar een geheim adres voldoende beveiliging?



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 A7.3: Wat laat je site prijs bij het inloggen?

Deze controle vraagt paden op die je alleen bij je eigen site laat nakijken. Klik eerst op "Toon mijn code" en zet die code als TXT-record op _weboke-cursus.<jouw domein> of als bestand op je site (zie de uitleg bij de code).



Wat je invult en wat we vinden, slaan we niet op. Je browser onthoudt je antwoorden en of je de opdracht hebt gehaald. Ben je aangemeld, dan bewaren we alleen dat je de opdracht (bijna) goed had in Mijn cursussen; daar kun je het ook verwijderen.

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.




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.

Even geduld…

Stel je domeinen in

Regel per domein de nameservers, de koppeling aan je hosting en wie de eigenaar wordt.

Je domeinen laden…