Passwordless login WordPress: passkeys of magic links

Passwordless login WordPress lost twee problemen tegelijk op die je met wachtwoordbeleid alleen nooit helemaal wegkrijgt: de eindeloze brute-force-aanvallen op wp-login.php en de zwakke wachtwoorden die klanten hergebruiken van hun webshop van 2018. De oplossing is niet één methode voor iedereen. Voor je admins wil je iets phishing-resistants (passkeys). Voor je klanten wil je iets met bijna nul friction (magic links). Dit artikel loopt beide af, geeft een beslismatrix per doelgroep, en behandelt de fallback-strategie die je vergeet als je alleen naar de “gelukkige pad”-flow kijkt.

WordPress-focus, met kort een verwijzing naar hoe hetzelfde werkt op Laravel en Statamic. Op andere stacks is het patroon hetzelfde; alleen de plugin-namen verschillen.

Werkplek voor passwordless login op WordPress met Face ID en hardware key

Waarom een wachtwoord in 2026 een zwakke schakel blijft

Wachtwoorden zijn niet dood, maar ze zijn wél de meest voorspelbare aanvalsvector. Twee dingen gaan mis:

Op de admin-kant blijft wp-login.php een van de meest aangevallen endpoints van het hele web. Zelfs met sterke wachtwoorden en 2FA is een gecompromitteerde admin-mailbox een pad naar een gecompromitteerde site.
Op de klant-kant hergebruiken mensen wachtwoorden over sites heen. Elke credential-dump ergens ter wereld is potentieel toegang tot jouw WooCommerce-accounts.

Passwordless authenticatie haalt het wachtwoord weg als aanvalsvector. Niet als je een tweede login-methode ernaast laat staan (dan verplaats je het probleem niet, je voegt een pad toe) — maar wél als je de standaard wachtwoord-login uitschakelt of tot een fallback met extra checks reduceert.

Schematische vergelijking tussen passkeys en magic links voor WordPress

Passkeys (WebAuthn / FIDO2) — hoe het werkt

Bij passkeys staat de publieke sleutel op de WordPress-server en de privésleutel in de Secure Enclave (Apple), TPM (Windows) of hardware key (YubiKey, SoloKey). Inloggen betekent: browser vraagt de sleutel, het device ontgrendelt hem met Face ID / Touch ID / Windows Hello / een tik op de key, en de server verifieert het antwoord.

Twee eigenschappen zijn belangrijk:

Phishing-resistant. De sleutel is gebonden aan het exacte domein. Een phishing-site met een lookalike-URL krijgt de sleutel simpelweg niet.
Device-gebonden. Wie geen toegang tot een geregistreerd device heeft, kan niet inloggen. Dat is de kracht én de valkuil (zie fallback verderop).

Plugins die dit fatsoenlijk implementeren op de wordpress.org-repo: Secure Passkeys plugin op WordPress.org, Multidots Passkey Login, WP Passkey. Alle drie leunen op de standaard WordPress authentication-API, dus geen exotische hooks.

Magic links — hoe het werkt

Bij magic links vult de gebruiker zijn e-mailadres in, krijgt een one-time link (5 tot 15 minuten geldig, single-use) en klikt zich in. Geen device-registratie, geen configuratie, geen wachtwoord. Werkt op elke desktop en elk mobiel apparaat.

Het zwakke punt is expliciet: de veiligheid van de login zit in de veiligheid van de e-mailinbox van de gebruiker. Wordt zijn mailaccount gecompromitteerd, dan is jouw site dat feitelijk ook. Voor consumer-accounts is dat een geaccepteerde afweging; voor admin-toegang is het een no-go.

Op WordPress.org: de Magic Login-plugin is de meest gebruikte optie. Zorg wel dat je transactionele mail via SPF/DKIM/DMARC verstuurt, anders komen je login-links in de spamfolder terecht en verlies je conversie.

Beslissingsmatrix per doelgroep

Beslismatrix passwordless login voor admins, klanten en ledenportals

Één methode voor iedereen levert altijd óf te veel friction, óf te weinig bescherming. Split per doelgroep:

Admins en redacteuren (2 tot 20 mensen, bekende devices): passkeys. Verplicht ze als vervanging van het wachtwoord of als tweede factor die de standaard-login blokkeert. Managed devices met Face ID / Windows Hello werken uit-de-doos.
WooCommerce-klanten (honderden tot duizenden, onbekende devices): magic links. Lage friction, geen registratie-drempel, werkt op elk device. Passkeys forceren op deze doelgroep leidt tot conversiepijn omdat een deel van je klanten oude Android-devices of gedeelde computers gebruikt.
Leden in een besloten portal (tussen 20 en 500 gebruikers): hangt af van het device-park. Managed IT met bekende devices → passkeys met hardware-key als backup. Bring-your-own-device met wisselende telefoons → magic links met sterke rate-limit.

Concreet voorbeeld: webshop met 3.000 klanten en 6 admins? Magic links voor klanten, passkeys voor admins, standaard wachtwoord-login voor beide doelgroepen uit. Voor gedeelde inlog voor team-accounts (marketing-mailbox, boekhouding) is een gedeelde inlog voor team-accounts via een password manager de betere route dan een tweede persoon aan een passkey te knopen.

Bureau met 8 redacteuren en één klantenportal voor 40 leden? Passkeys voor iedereen, magic links als backup voor als iemand zijn device kwijt is.

Fallback en account-recovery

Passwordless zonder fallback is een tijdbom. De vraag is niet óf iemand zijn device verliest, maar wanneer. Twee scenario’s, twee patronen.

Bij passkeys:

Minimaal één backup-methode per account: een tweede passkey op een ander device (laptop plus telefoon), óf een set eenmalige recovery-codes die de gebruiker afdrukt en veilig bewaart.
Voor admins: verplicht een hardware key (YubiKey of vergelijkbaar) als backup. Kost eenmalig zo’n 50 euro per admin en scheelt paniek bij een verloren telefoon.
Recovery via de admin: alleen als je een tweede factor voor de admin-recovery-flow hebt (bijvoorbeeld persoonlijke bevestiging), anders is het gat weer terug.

Voor de basis van je 2FA-setup en recovery-flow: kijk parallel naar bestaande 2FA-setup evalueren — passwordless is een aanvulling, geen vervanging voor doordacht account-recovery-beleid.

Bij magic links:

Rate-limit op het aanvragen van links: maximaal drie per e-mailadres per 15 minuten, en per IP maximaal 20 per uur. Zonder rate-limit is de link-endpoint een spam-vector.
One-time-use, kort geldig (5-15 min), en invalidate bij succesvolle login.
Bounce-monitoring: als de link niet aankomt vanwege spamfilter of foutief adres, moet de gebruiker een alternatief zien (contact opnemen, of tijdelijk wachtwoord-login als noodgreep).

Wat je NIET moet doen

Vier klassieke fouten die passwordless-implementaties waardeloos maken:

Passkeys forceren op klanten zonder fallback. Oude Android-telefoons zonder biometrics, gedeelde huiscomputers, klanten die inloggen vanaf werk-Windows zonder Hello — een deel van je gebruikersbestand valt gewoon buiten passkey-support. Fallback is verplicht.
Magic links met te lange geldigheid. Alles boven 15 minuten geeft aanvallers ruimte om een gestolen link te gebruiken. Alles boven 1 uur is roekeloos.
Beide methoden aanzetten zonder de standaard-wachtwoord-login uit te schakelen. Dit is de meest voorkomende fout: passwordless als optionele extra, wachtwoord-login blijft actief. Netto: je hebt een extra aanvalspad toegevoegd, niet een aanvalspad verwijderd.
Alleen kijken naar de gelukkige-pad-flow. Test wat er gebeurt als de gebruiker zijn e-mail niet kan openen, zijn telefoon kwijt is, of een nieuwe passkey op een tweede device wil toevoegen. Als één van die flows kapot is, val je terug op support-tickets.

Passwordless op andere stacks — kort

De WordPress-focus hierboven vertaalt goed naar andere stacks:

Laravel: laravel/passkeys of laravel/webauthn voor passkeys, plus de ingebouwde magic-link-flow via Laravel::magicLink() (of custom via signed URLs). Middleware-patroon in plaats van plugin.
Statamic: built-in support voor 2FA en passwordless via addons; de standaard laravel/passkeys werkt hier ook omdat Statamic op Laravel draait.
Headless / eigen frontend: WebAuthn via @simplewebauthn/browser en @simplewebauthn/server. Meest werk, meest controle.

De filosofie is overal identiek: passkeys voor high-trust rollen, magic links voor low-friction consumer-flows, fallback als eerste-klasse-feature.

Wanneer schakel je Lypii in

Een passwordless-setup op een reguliere WordPress-site kost bij één gekozen methode ongeveer 2 tot 4 uur werk: plugin installeren, configureren, standaard-login netjes uitschakelen (of alleen bereikbaar via admin-IP), fallback-flow inrichten en test-accounts doorlopen. Voor een kleine site is een fix van €70 voor één methode passend; bij twee methoden (passkeys admin + magic links klant) of aanvullende recovery-flows werk ik op €105 per uur.

Structureel onderhoud (nieuwe redacteuren, key-rotatie, plugin-updates checken) valt onder het support-abonnement van €95 per maand.

Verbeteren boven herbouwen: passwordless is een pluggable laag op je bestaande WordPress-login. Geen nieuwe site, geen migratie.

Multi-stack opmerking: dezelfde beslismatrix werkt op Laravel, Statamic en headless setups. WordPress heeft alleen het voordeel dat er kant-en-klare plugins bestaan; op andere stacks moet je iets meer eigen middleware schrijven.