Joomla Multi-factor Authenticatie: TOTP, WebAuthn, Passkeys

Op deze pagina

# Topics

veiligheid

Joomla Multi-factor Authenticatie: TOTP, WebAuthn, Passkeys

16 augustus 2026

Een wachtwoord alleen is niet langer voldoende om een account te beveiligen. Wachtwoorden worden gestolen via phishing, geraden, gelekt bij datalekken en hergebruikt op verschillende websites. Joomla wordt geleverd met een compleet systeem voor meervoudige authenticatie (MFA) dat een tweede beveiligingslaag toevoegt aan elk account: een authenticatie-app, een beveiligingssleutel, een passkey of een code per e-mail. Het is ingebouwd in de kern, het is gratis en de meeste site-eigenaren hebben het scherm waar het zich bevindt nog nooit geopend.

Dit artikel legt uit hoe Multi-factor Authenticatie echt werkt in Joomla. Het behandelt de basis voor site-eigenaren, de instellingen en het beleid voor beheerders, en de technische details - databasetabellen, versleuteling, events en de WebAuthn-plugins - voor ontwikkelaars.

MFA is geen plug-in die je kunt kopen. Het is een standaardfunctie van Joomla die je alleen nog maar hoeft aan te zetten.

Het doel is simpel: je Joomla's MFA goed genoeg laten begrijpen om vandaag je eigen account te beschermen en morgen MFA voor anderen af te dwingen.

1. De basis

1.1 Wat is Multi-factor Authenticatie?

Authenticatiefactoren komen in drie soorten:

Iets dat je weet - een wachtwoord of pincode.
Iets dat je hebt - een telefoon met een authenticator-app, een hardware security key, een e-mailinbox.
Iets dat je bent - een vingerafdruk of een gezichtsscan.

Multi-factor Authenticatie betekent dat de login minimaal twee verschillende soorten vereist. Een aanvaller die je wachtwoord steelt kan nog steeds niet inloggen, want hij heeft je telefoon of je security key niet. Die ene extra stap blokkeert de meest voorkomende accountovernames vrijwel volledig.

1.2 Wat Joomla biedt

Joomla's huidige MFA-systeem kwam in Joomla 4.2 als een complete herbouw van de oudere "Twee-factor authenticatie" (2FA) uit Joomla 3. Het leeft in de core gebruikerscomponent (com_users) en werkt hetzelfde aan de frontend en in de administrator-backend:

Je logt zoals gewoonlijk in met je gebruikersnaam en wachtwoord.
Joomla controleert of je account een MFA-methode heeft ingesteld.
Zo ja, dan kom je op een afgesloten captive-pagina die niets anders accepteert dan je tweede factor.
Pas nadat de tweede factor is gevalideerd laat Joomla je door naar de eigenlijke site.

De afzonderlijke MFA-methodes zijn plugins in een eigen plugin-groep, multifactorauth. Je vindt ze onder Systeem → Plugins, gefilterd op de map multifactorauth.

1.3 MFA en passkeys zijn twee verschillende functies

Dit is het meest voorkomende verwarringspunt, dus laten we het meteen ophelderen. Joomla bevat twee aparte functies die dezelfde WebAuthn-browsertechnologie gebruiken:

Multi-factor Authenticatie - Web Authentication (plugin-groep multifactorauth): je logt eerst in met je wachtwoord en bevestigt daarna met een security key of platform-authenticator als tweede factor.
System - WebAuthn Passwordless Login (plugin-groep system): je slaat het wachtwoord volledig over en logt in met alleen een passkey of security key.

Beide staan standaard aan, beide bewaren hun gegevens in verschillende databasetabellen, en je kunt ze allebei tegelijk gebruiken. Sectie 6 behandelt ze in detail.

Naar boven

2. De ingebouwde MFA-methodes

2.1 De vijf plugins

Joomla levert vijf MFA-plugins mee. Vier staan standaard aan; een is een demonstratieplugin die uit blijft:

Plugin	Wat hij doet	Standaard
Verificatiecode (TOTP)	Zescijferige codes uit een authenticator-app zoals Google Authenticator, Microsoft Authenticator, FreeOTP of een wachtwoordmanager.	Aan
Web Authentication (WebAuthn)	Een hardware security key (YubiKey, Titan) of een platform-authenticator (Windows Hello, Touch ID) bevestigt de login met een cryptografische handtekening.	Aan
YubiKey	Het klassieke YubiKey-eenmalige-wachtwoord: raak de key aan, hij typt een code van 44 tekens, Joomla valideert die bij de YubiCloud-servers van Yubico.	Aan
E-mail	Joomla mailt je een zescijferige code die een korte tijd geldig is.	Aan
Vaste code	Een statisch tweede wachtwoord. Bestaat als demonstratie voor ontwikkelaars die de MFA-plugin-API willen leren.	Uit

Bovenop deze plugins genereert Joomla automatisch back-upcodes (sectie 3.3) zodra je voor het eerst een methode instelt. Back-upcodes zijn geen plugin - ze zijn een ingebouwde functie van com_users.

2.2 Hoe TOTP werkt

TOTP staat voor Time-based One-Time Password, gestandaardiseerd in RFC 6238. Tijdens de setup genereert Joomla een willekeurig geheim van 20 bytes (160 bits) en toont dat als QR-code. Je authenticator-app bewaart het geheim en berekent vanaf dat moment een zescijferige code uit het geheim plus de actuele tijd, in stappen van 30 seconden. Joomla kent hetzelfde geheim, berekent dezelfde code en vergelijkt. Er is geen netwerkverbinding tussen je telefoon en de site nodig - alleen redelijk gelijklopende klokken.

2.3 Hoe de e-mailmethode werkt

De e-mailplugin gebruikt dezelfde TOTP-wiskunde maar met een langere tijdstap: de gemailde code is standaard 2 minuten geldig (instelbaar tussen 30 seconden en 15 minuten in de plugin-opties). Denk goed na voordat je alleen op deze methode vertrouwt: als de e-mailbezorging van je site stuk gaat, gaat je login mee stuk. De plugin heeft ook een optie forceer deze MFA-methode voor alle gebruikers: staat die aan, dan krijgt elke gebruiker die al MFA gebruikt automatisch de e-mailmethode als extra optie erbij, met het adres uit zijn gebruikersaccount.

2.4 Welke methode kies je?

Beste beveiliging: Web Authentication met een hardware key of platform-authenticator. Phishing-bestendig - de browser ondertekent de challenge alleen voor het exacte domein dat de key registreerde.
Beste balans: TOTP met een authenticator-app. Gratis, offline, werkt overal.
Alleen als vangnet: E-mail. Beter dan niets, maar afhankelijk van je mailserver en van de beveiliging van de mailbox zelf.

Je kunt - en zou moeten - meer dan een methode registreren. Op de captive-pagina kies je bij elke login welke je gebruikt.

Een methode die je niet in de lijst vindt: sms-codes. Dat is bewust, geen vergissing. Sms-berichten kunnen worden onderschept en een telefoonnummer kan met een SIM-swap bij de telefoonwinkel worden gekaapt; daarom raden beveiligingsrichtlijnen sms-codes al jaren af. Joomla heeft de zwakke optie simpelweg nooit gebouwd.

Naar boven

3. MFA instellen op je eigen account

3.1 Waar je het vindt

In de administrator-backend: klik op je gebruikersnaam rechtsboven, kies Account bewerken en open het tabblad Multi-factor authenticatie. Aan de frontend: log in en open je profielbewerkpagina; daar verschijnt dezelfde interface. Bezoekers zien hier nooit iets van - MFA-schermen bestaan alleen voor ingelogde gebruikers.

Een belangrijke regel, afgedwongen in de code: je kunt alleen MFA-methodes toevoegen of bewerken op je eigen account. Zelfs een Super User kan geen MFA instellen voor een andere gebruiker. Dat is bewust - een tweede factor die iemand anders voor jou instelde zou geen "iets dat je hebt" zijn.

3.2 Een TOTP-methode toevoegen, stap voor stap

Open het tabblad Multi-factor authenticatie en klik op Verificatiecode.
Joomla toont een QR-code. Scan die met je authenticator-app.
De app toont nu zescijferige codes. Typ de actuele code in het setupformulier om te bewijzen dat de koppeling werkt.
Opslaan. Vanaf de volgende login vraagt Joomla om een code.

3.3 Back-upcodes: print ze nu

De eerste keer dat je een MFA-methode opslaat genereert Joomla tien back-upcodes, elk acht cijfers lang (twee groepen van vier). Elke code werkt precies een keer als vervanging van je normale tweede factor. Ze bestaan voor de dag dat je telefoon kwijt, kapot of gewist is.

Print ze of bewaar ze in een wachtwoordmanager - nu, niet later. Je kunt de hele set op elk moment opnieuw genereren vanaf hetzelfde scherm; opnieuw genereren maakt alle oude codes ongeldig.

3.4 De standaardmethode

Registreer je meerdere methodes, dan kun je er een markeren als standaard. De captive-pagina selecteert die alvast bij het inloggen; de andere blijven bereikbaar achter een link "gebruik een andere methode".

Naar boven

4. MFA voor beheerders

4.1 De beleidsopties

Al het site-brede MFA-beleid staat in Systeem → Algemene configuratie → Gebruikers → Multi-factor authenticatie (de opties van com_users). De belangrijke velden:

Optie	Wat hij doet
`neverMFAUserGroups`	Gebruikersgroepen die nooit MFA zien. Handig voor machine-accounts of in bulk geimporteerde gebruikers.
`forceMFAUserGroups`	Gebruikersgroepen die MFA moeten gebruiken. Leden zonder methode worden doorgestuurd naar de setuppagina en kunnen de site niet gebruiken tot ze er een instellen.
`mfaonsilent`	Of "stille" logins (zie 4.3) ook langs MFA moeten. Standaard: Nee.
`mfaredirectonlogin` / `mfaredirecturl`	Toon na het inloggen een eenmalige pagina "stel MFA in" voor gebruikers die nog niets hebben ingesteld. Gebruikers mogen op "niet meer tonen" klikken.
`mfatrycount` / `mfatrytime`	Brute-force-bescherming: maximum aantal foute pogingen per methode (standaard 10) en hoe lang de methode daarna geblokkeerd is (standaard 1 uur).
`captive_template`	Gebruik een andere templatestijl voor de captive-pagina aan de frontend.
Toegestane moduleposities	Welke moduleposities nog mogen renderen op de captive-pagina (frontend en backend apart). Standaard: geen.

Een subtiele regel uit de broncode: zit een gebruiker zowel in een "nooit MFA"-groep als in een "forceer MFA"-groep, dan wint forceren. De veiligste instelling gaat altijd voor.

4.2 MFA afdwingen voor beheerders

Het meest waardevolle MFA-beleid op een gemiddelde site: zet je groepen Administrator en Super Users in forceMFAUserGroups. Vanaf dat moment moet elke backend-beheerder bij zijn volgende login eerst MFA instellen voordat Joomla hem iets anders laat doen. Joomla bewaart voor deze gebruikers een sessievlag zodat ze de verplichting niet kunnen omzeilen door een methode aan te zetten en in dezelfde sessie weer te verwijderen.

4.3 Stille logins

Twee soorten logins gebruiken geen getypt wachtwoord: de "Onthoud mij"-cookie en de passwordless WebAuthn-login. Standaard (mfaonsilent = Nee) slaan die de captive-pagina over: de cookie bewijst een eerdere volledige login, en een passkey bewijst al het bezit van een fysieke authenticator. Welke responstypes als stil gelden is instelbaar (standaard: cookie, passwordless). Eist jouw beveiligingsbeleid MFA bij elke sessie, zet mfaonsilent dan op Ja.

4.4 Een buitengesloten gebruiker helpen

Gebruikers raken telefoons kwijt. Een Super User kan het account van de buitengesloten gebruiker openen en zijn MFA-methodes verwijderen (geen nieuwe toevoegen - zie 3.1), waardoor het account teruggaat naar inloggen met alleen een wachtwoord en de gebruiker MFA opnieuw kan instellen. Twee beschermingen gelden, rechtstreeks uit de permissiechecks in de code: je hebt core.admin-rechten (Super User) nodig, en je kunt nooit de MFA van een andere Super User resetten. Twee Super Users beheren elk hun eigen tweede factor - of een van hen moet naar de database (sectie 10.2).

Naar boven

5. De captive-pagina

5.1 Een pagina waar je niet omheen kunt

Nadat de wachtwoordlogin slaagt, controleert Joomla's applicatie-object de sessievlag com_users.mfa_checked. Staat die niet en heeft je account een actieve MFA-methode, dan wordt elk verzoek beantwoord met een HTTP 307-redirect naar:

index.php?option=com_users&view=captive

Deze "captive"-pagina toont geen menu's en geen modules (tenzij een beheerder expliciet posities heeft toegestaan), dus er valt niets te klikken behalve het codeveld, een methodekiezer en de uitloglink. Joomla houdt uitloggen bewust bereikbaar - voor de dag dat je daar staat zonder je telefoon.

5.2 Wat er ondertussen geblokkeerd is

Zolang MFA openstaat wordt elk verzoek om een niet-HTML-formaat - format=json, format=raw, enzovoort - geweigerd met een harde HTTP 403-fout. Dat voorkomt dat scripts en AJAX-endpoints als achterdeur om de captive-pagina heen worden gebruikt. De code maakt precies een functionele uitzondering: de afrondingsstappen van een Joomla core-update mogen door, zodat een update die toevallig samenvalt met een MFA-prompt de site niet half bijgewerkt kan achterlaten.

5.3 Brute-force-bescherming

Elke foute code verhoogt een tellerkolom per methode in de database. Na mfatrycount mislukkingen (standaard 10) is de methode mfatrytime uur geblokkeerd (standaard 1). Na afloop van het blokkeervenster begint de teller opnieuw. In combinatie met de 30-secondenrotatie van TOTP-codes is het raden van een zescijferige code geen realistische aanval.

Naar boven

6. WebAuthn en passkeys

6.1 Hoe WebAuthn werkt

WebAuthn (de W3C Web Authentication-standaard) vervangt gedeelde geheimen door publieke-sleutelcryptografie. Bij registratie maakt je authenticator - een USB security key, je telefoon, of de platform-authenticator in je laptop - een sleutelpaar voor dat exacte domein. De prive-sleutel verlaat het apparaat nooit. Bij het inloggen stuurt de site een willekeurige challenge, de authenticator ondertekent die, en de site verifieert de handtekening met de bewaarde publieke sleutel.

Er zoemen nogal wat namen rond deze technologie, dus hier is de plattegrond. De standaarden komen van de FIDO Alliance samen met het W3C. FIDO2 is de overkoepelende specificatie met twee delen: WebAuthn, de browser-API waar websites zoals Joomla mee praten, en CTAP (Client to Authenticator Protocol), waarmee de browser met de authenticator zelf praat. En een passkey is simpelweg de consumentvriendelijke naam voor een WebAuthn-credential.

Twee eigenschappen maken dit de sterkste optie die Joomla biedt:

Phishing-bestendig: de browser weigert de key te gebruiken op elk ander domein dan het domein dat hem registreerde. Een nagemaakte look-alike-site vangt niets.
Niets nuttigs te stelen: de server bewaart alleen publieke sleutels. Een databaselek brengt de tweede factor niet in gevaar.

Een harde eis, vastgelegd in de W3C-specificatie en afgedwongen door elke browser: WebAuthn werkt alleen over HTTPS. Op een site met kaal HTTP verschijnen beide WebAuthn-functies van Joomla stilletjes niet.

6.2 Als tweede factor (MFA)

De plugin Multi-factor Authenticatie - Web Authentication registreert de authenticator als MFA-methode. De setup is een browserdialoog: Joomla vraagt de browser een credential aan te maken, jij raakt je key aan of bevestigt de biometrische prompt, klaar. Bij elke volgende login opent de captive-pagina na je wachtwoord dezelfde browserprompt in plaats van een codeveld. Het credential-ID en de publieke sleutel worden - versleuteld - bewaard in de opties van de methode in de tabel #__user_mfa.

De aparte plugin System - WebAuthn Passwordless Login gaat een stap verder en vervangt het wachtwoord. Je voegt eerst een passkey toe in je gebruikersprofiel (daar verschijnt een veld "W3C Web Authentication (WebAuthn) Login" zolang je over HTTPS browset). Daarna toont elk Joomla-loginformulier - frontend en backend - een extra knop Web Authentication naast de normale inlogknop.

Een detail dat het weten waard is, geverifieerd in de plugin-broncode: Joomla's implementatie vraagt je om eerst je gebruikersnaam te typen en dan op de knop te klikken; een verzoek met een lege gebruikersnaam wordt afgewezen voordat er ook maar een browserdialoog opent. Het is een passwordless login, geen usernameless login - anders dan sommige passkey-implementaties elders die je herkennen aan alleen de credential.

Moderne passkeys kunnen ook reizen. Apple, Google en Microsoft synchroniseren ze - end-to-end versleuteld - tussen je apparaten via iCloud-sleutelhanger of Google Wachtwoordmanager, en browsers bieden cross-device inloggen: je desktop toont een QR-code, jij scant die met je telefoon, en de telefoon ondertekent de challenge. Dit gebeurt allemaal aan de kant van de browser en het besturingssysteem; Joomla verifieert alleen het ondertekende antwoord, dus het werkt zonder enige Joomla-configuratie. Het heeft wel een gevolg: het cloudaccount dat je passkeys synchroniseert wordt onderdeel van je beveiligingsketen, dus bescherm ook dat account met MFA.

Deze credentials leven in een eigen tabel, #__webauthn_credentials, volledig gescheiden van MFA. En zoals sectie 4.3 uitlegde: een passwordless login telt als stil responstype en slaat de MFA-captive-pagina standaard over - de fysieke authenticator bewees het bezit al.

Naar boven

7. Onder de motorkap (ontwikkelaarsblik)

7.1 De databasetabellen

Elke ingestelde MFA-methode is een rij in #__user_mfa:

Kolom	Doel
`id`	Primaire sleutel.
`user_id`	Het account waar deze methode bij hoort.
`title`	Het zichtbare label ("Verificatiecode", "Mijn YubiKey", …).
`method`	De methodenaam van de plugin: `totp`, `webauthn`, `yubikey`, `email`, `fixed` of `backupcodes`.
`default`	1 voor de voorgeselecteerde methode op de captive-pagina.
`options`	De configuratie van de methode (TOTP-geheim, WebAuthn-credential, back-upcodes) - versleuteld, zie 7.2.
`created_on`, `last_used`	Tijdstempels.
`tries`, `last_try`	De brute-force-tellers uit sectie 5.3.

De passwordless-loginplugin gebruikt een eigen tabel, #__webauthn_credentials, met het credential-ID, een user handle, een label en de credential-brongegevens als JSON. Die JSON bevat ook een signature counter: de meeste authenticators verhogen die bij elke login, Joomla bewaart de laatst bekende waarde, en de meegeleverde bibliotheek web-auth/webauthn-lib weigert een assertion waarvan de teller niet vooruit is gegaan. Een gekloonde credential verraadt zichzelf, want twee kopieen kunnen nooit een teller synchroon houden.

7.2 De opties zijn versleuteld met je site-secret

Voordat een rij wordt opgeslagen versleutelt de encryptieservice van de component de JSON-gecodeerde options met AES, met als sleutel de waarde van $secret uit de configuration.php van je site. Dat heeft een gevolg dat mensen tijdens migraties verrast: verandert de secret, dan is elke opgeslagen MFA-methode niet meer te ontsleutelen en verliezen alle gebruikers feitelijk hun tweede factor. Kloon of verhuis je een site, behoud dan de secret - of plan een herregistratie van MFA.

7.3 De applicatie-handler

De captive-logica is geen plugin. Het is de trait MultiFactorAuthenticationHandler in libraries/src/Application/, gebruikt door precies twee applicatieklassen: SiteApplication en AdministratorApplication. De codecommentaren leggen uit waarom: MFA is per definitie interactief, dus de CLI-applicatie (impliciet vertrouwd) en de API-applicatie (token-gebaseerd, zie sectie 8) gebruiken hem niet. De trait onderhoudt twee sessievlaggen: com_users.mfa_checked (gezet zodra de tweede factor is gevalideerd, of meteen als het account geen methodes heeft) en com_users.mandatory_mfa_setup (houdt leden van een geforceerde groep vast op de setuppagina).

7.4 Migratie vanaf Joomla 3 Twee-factor authenticatie

De oude Joomla 3-functie bewaarde zijn gegevens in de kolommen otpKey en otep van #__users. De handler migreert dit per gebruiker, bij zijn eerste captive-login - niet site-breed tijdens de Joomla-update, een bewuste keuze om te voorkomen dat de update vastloopt op sites met duizenden gebruikers. Oude TOTP- en YubiKey-instellingen worden rijen in #__user_mfa; oude noodcodes worden back-upcodes; de oude kolommen worden daarna leeggemaakt.

7.5 Je eigen MFA-methode schrijven

Een MFA-plugin is een normale Joomla-plugin in de groep multifactorauth die zich abonneert op vijf events uit Joomla\CMS\Event\MultiFactor:

public static function getSubscribedEvents(): array
{
    return [
        'onUserMultifactorGetMethod' => 'onUserMultifactorGetMethod', // beschrijf de methode
        'onUserMultifactorGetSetup'  => 'onUserMultifactorGetSetup',  // render het setupformulier
        'onUserMultifactorSaveSetup' => 'onUserMultifactorSaveSetup', // valideer + bewaar opties
        'onUserMultifactorCaptive'   => 'onUserMultifactorCaptive',   // render het captive-formulier
        'onUserMultifactorValidate'  => 'onUserMultifactorValidate',  // controleer de ingestuurde code
    ];
}

GetMethod geeft een MethodDescriptor terug (naam, weergavetitel, korte info, icoon). GetSetup en Captive geven render-optie-objecten terug die het invoerveld beschrijven; Validate ontvangt het record, de gebruiker en de ingestuurde code en geeft true of false terug. De uitgeschakelde plugin Vaste code bestaat precies als minimaal, leesbaar voorbeeld van alle vijf - zijn eigen taalstrings zeggen het letterlijk. Er bestaan extra events voor bijzondere gevallen: Callback (voor methodes die een extern rondje nodig hebben), BeforeDisplayMethods (de e-mailplugin gebruikt hem voor de forceer-functie) en NotifyActionLog (voedt het actielog).

Naar boven

8. MFA, de Web Services API en de CLI

8.1 De API gebruikt geen MFA

Joomla's REST API (/api/index.php/v1/…) authenticeert elk verzoek met een API-token (of Basic-authenticatie), niet met een sessie - er is dus geen inlogmoment waarop een captive-pagina zou kunnen verschijnen, en de handler-trait zit simpelweg niet in de API-applicatie. Bescherm de API zoals hij ontworpen is om beschermd te worden: met de token-plugins, over HTTPS, alleen toegekend aan de accounts die het nodig hebben. Het authenticatie-artikel behandelt het tokenmechanisme in de diepte.

8.2 Maar MFA bewaakt wel de token

Indirect doet MFA er voor de API wel degelijk toe: de API-token wordt aangemaakt en getoond in het gebruikersprofiel. Een aanvaller die niet langs je captive-pagina komt, kan niet inloggen om je token te kopieren. De interactieve login beveiligen beveiligt ook de inloggegevens die de niet-interactieve clients gebruiken.

8.3 CLI

Commando's via cli/joomla.php draaien als een impliciet geautoriseerde gebruiker - wie shell-toegang heeft, wordt vertrouwd. MFA speelt daar geen rol. Het praktische gevolg: de SSH-configuratie van je server hoort bij de beveiligingsperimeter van je Joomla-site.

Naar boven

9. SEO en metadata

MFA heeft geen direct SEO-oppervlak - en dat moet precies zo blijven:

De captive-pagina en de MFA-setuppagina's bestaan alleen voor ingelogde gebruikers; zoekmachinecrawlers krijgen ze nooit te zien. Er valt niets te indexeren en niets te optimaliseren.
Houd je frontend-loginpagina zelf uit de index (een noindex-robotsinstelling op het login-menu-item) - loginpagina's in zoekresultaten nodigen alleen maar uit tot wachtwoord-raadverkeer.
Gebruik je een aparte templatestijl voor de captive-pagina (captive_template), houd die dan bewust minimaal: geen analytics, geen marketingscripts. Minder scripts van derden op een authenticatiepagina betekent ook een kleiner aanvalsoppervlak.
Indirect beschermt MFA je SEO: een gekaapt beheerdersaccount dat spamlinks injecteert kan een site maanden aan rankings kosten. De goedkoopste SEO-verzekering die een Joomla-site kan krijgen is MFA op elk backend-account.

Naar boven

10. Veelvoorkomende fouten en valkuilen

10.1 Geen back-upcodes, telefoon kwijt

Symptoom: Een gebruiker heeft een nieuwe telefoon, de authenticator-app is weg, en de captive-pagina laat hem er niet in.

Oplossing: Eerste keus: gebruik een van de tien back-upcodes. Zijn die nooit bewaard: een Super User verwijdert de MFA-methodes van de gebruiker via zijn gebruikersaccount (sectie 4.4), de gebruiker logt in met alleen zijn wachtwoord en registreert opnieuw. Preventie: behandel "print de back-upcodes" als onderdeel van de setup, niet als optioneel.

10.2 De buitengesloten Super User

Symptoom: De enige Super User is buitengesloten, en er is geen andere Super User om hem te resetten.

Oplossing: Databasetoegang is de nooduitgang. De rijen van de gebruiker verwijderen uit #__user_mfa haalt zijn methodes weg; de multifactorauth-plugins uitschakelen in #__extensions (zet enabled op 0) schakelt de functie site-breed uit. Daarna: weer inschakelen en opnieuw registreren. Kun je bij phpMyAdmin of de MySQL CLI, dan sta je twee UPDATE-statements van je site af - wat meteen laat zien hoe belangrijk databasegegevens zijn.

10.3 De WebAuthn-knop ontbreekt

Symptoom: Geen Web Authentication-knop op het loginformulier, geen WebAuthn-optie tijdens de MFA-setup.

Oplossing: Controleer het protocol. WebAuthn vereist HTTPS volgens de W3C-specificatie; op kaal HTTP verbergt Joomla de functie in plaats van een kapotte knop te tonen. Gebruik op een lokale ontwikkelsite een lokaal vertrouwd certificaat (bijvoorbeeld via mkcert) in plaats van over HTTP te werken.

10.4 E-mail-MFA op een site met kapotte mail

Symptoom: Gebruikers met de e-mailmethode wachten op codes die nooit aankomen; feitelijk zijn ze buitengesloten.

Oplossing: Test de mailbezorging (Algemene configuratie → Server → Testmail versturen) voordat iemand op de e-mailmethode vertrouwt, en stimuleer TOTP of WebAuthn als hoofdmethode met e-mail hooguit als vangnet. Gebeurt het toch: back-upcodes of een beheerdersreset.

10.5 De plugin Vaste code aanzetten in productie

Symptoom: Gebruikers "beveiligen" hun account met een statisch tweede wachtwoord.

Oplossing: Laat de plugin Vaste code uitgeschakeld. Het is een ontwikkelaarsdemonstratie - zijn eigen beschrijving zegt het. Een vaste code is gewoon een tweede wachtwoord: het kan gephisht, gelekt en hergebruikt worden, precies zoals het eerste, en voegt dus geen echte tweede factor toe.

10.6 Verwachten dat MFA de REST API beschermt

Symptoom: MFA is afgedwongen voor alle groepen, en de aanname is dat de API-endpoints er nu ook achter zitten.

Oplossing: Dat zitten ze niet (sectie 8). API-toegang wordt bewaakt door tokens. Controleer welke gebruikers een actieve API-token hebben, schakel de token-plugins uit als je de API helemaal niet gebruikt, en behandel tokens met dezelfde zorg als wachtwoorden.

Symptoom: De backend is beschermd met een geheime URL-sleutel - bijvoorbeeld met de gratis plugin AdminExile, die /administrator/ verbergt tenzij de bezoeker een geheime sleutel aan de URL toevoegt - en MFA wordt onnodig gevonden omdat "er al een tweede geheim is".

Oplossing: Houd de URL-sleutel, maar tel hem niet mee als factor. Een geheime URL is "iets dat je weet", net als je wachtwoord - twee kennisgeheimen zijn twee-staps, geen multi-factor, en een phishingpagina of keylogger vangt ze allebei tegelijk. Het is ook geen authenticatie: dezelfde statische sleutel wordt gedeeld door alle beheerders, hangt aan geen enkel gebruikersaccount en geeft alleen het recht om het loginformulier te zien. Tools als AdminExile zijn waardevolle perimeter-hardening - ze verbergen de login voor het constante botverkeer dat op elke Joomla-site inbeukt - maar ze verkleinen de blootstelling van het wachtwoord, terwijl MFA het compromitteren van het wachtwoord overleeft. Gebruik beide lagen samen.

10.8 Alle MFA kwijt na een site-verhuizing

Symptoom: Na het migreren van een site naar een nieuwe server of het opnieuw opbouwen van configuration.php werkt de tweede factor van geen enkele gebruiker meer.

Oplossing: De kolom options is versleuteld met de $secret van de site (sectie 7.2). Herstel de oorspronkelijke secret-waarde en de methodes zijn weer te ontsleutelen. Is de oude secret echt weg, verwijder dan de rijen uit #__user_mfa en laat gebruikers opnieuw registreren.

Naar boven

11. Best practices

Als je maar een paar dingen uit dit artikel onthoudt, onthoud dan deze:

Zet vandaag MFA aan op je eigen account - de functie is al geinstalleerd en ingeschakeld.
Zet je groepen Administrator en Super Users in Forceer multi-factor authenticatie; die accounts zijn wat aanvallers echt willen.
Kies bij voorkeur WebAuthn of TOTP; behandel de e-mailmethode als vangnet, nooit als enige methode.
Registreer twee methodes per account (bijvoorbeeld TOTP plus een security key), zodat een kwijtgeraakt apparaat een ongemak is en geen incident.
Bewaar de tien back-upcodes zodra ze verschijnen. Dat scherm is geen decoratie.
Houd de $secret in configuration.php ongewijzigd bij een site-verhuizing - of plan herregistratie.
Serveer de hele site over HTTPS; zonder HTTPS zijn de sterkste methodes niet eens beschikbaar.
Combineer MFA met de basis uit het artikel over Joomla beveiligen: updates, sterke unieke wachtwoorden en gebruikersgroepen met minimale rechten. MFA is een laag, geen vervanging.

Naar boven

12. In het kort

WAT                         WAAR / WAARDE
Je eigen MFA instellen      Backend: je naam (rechtsboven) > Account
                            bewerken > tab Multi-factor authenticatie
                            Frontend: Profiel bewerken > zelfde tab
Site-breed beleid           Algemene configuratie > Gebruikers
                            > Multi-factor authenticatie
Methode-plugins             Systeem > Plugins > filter op map
                            "multifactorauth"
Standaard ingeschakeld      TOTP, WebAuthn, YubiKey, E-mail
Uitgeschakelde demo-plugin  Vaste code (laat hem uit)
Back-upcodes                10 codes, 8 cijfers, eenmalig bruikbaar
TOTP-parameters             6 cijfers, stap van 30 s, RFC 6238
Geldigheid e-mailcode       standaard 120 s (30-900 s)
Blokkering na foute codes   10 pogingen, dan 1 uur geblokkeerd
                            (standaardwaarden)
URL captive-pagina          index.php?option=com_users&view=captive
Tabel MFA-methodes          #__user_mfa (options AES-versleuteld
                            met de secret uit configuration.php)
Passwordless credentials    #__webauthn_credentials
Buitengesloten gebruiker    Super User verwijdert de methodes van de
                            gebruiker (nooit bij een andere Super User)
Noodstop (SQL)              UPDATE #__extensions SET enabled = 0
                            WHERE folder = 'multifactorauth';
Bereik                      Alleen site + administrator;
                            API gebruikt tokens, CLI wordt vertrouwd

Naar boven

13. Samenvatting

Joomla levert een compleet Multi-factor Authenticatie-systeem in de core: TOTP-, WebAuthn-, YubiKey- en e-mailmethodes, plus eenmalig bruikbare back-upcodes.
Na de wachtwoordlogin eist een afgesloten captive-pagina de tweede factor; foute pogingen worden afgeremd, niet-HTML-verzoeken worden geblokkeerd met een 403.
Beheerders bepalen beleid per gebruikersgroep: sommige groepen zien MFA nooit, andere kunnen de site niet gebruiken zonder, en forceren wint altijd.
WebAuthn komt twee keer voor: als MFA-methode en als aparte passwordless-loginplugin - beide alleen over HTTPS, beide phishing-bestendig.
Onder de motorkap zijn methodes rijen in #__user_mfa met AES-versleutelde opties gekoppeld aan je site-secret, aangestuurd door een applicatie-trait en vijf plugin-events.
De REST API valt bewust buiten MFA - tokens bewaken die - en de CLI vertrouwt wie shell-toegang heeft.

MFA aanzetten kost vijf minuten. Het juiste beleid bepalen voor een site met veel gebruikersgroepen, accounts migreren vanaf oudere setups, of een site herstellen waar de authenticatie is misgegaan vraagt ervaring. Wil je een tweede paar ogen op hoe jouw Joomla-site omgaat met logins, accounts en toegang, dan loont het om iemand te laten meekijken die dagelijks met deze instellingen werkt.

Naar boven