Kort gezegd: een WordPress magic link is een lang, willekeurig token waarvan de HMAC-SHA256-hash — niet het token zelf — in je database wordt opgeslagen. Iedereen met de link komt binnen zonder wachtwoord; iedereen die je database steelt, krijgt een hash die niet terug te zetten is naar een werkende link. Dat is het hele beveiligingsmodel in één zin, en de rest van deze post legt uit waarom het standhoudt.
Het probleem met toegang delen op de oude manier
Als je ooit een klant een staging-URL of een gedeeld paginawachtwoord hebt gegeven, ken je de zwakke plekken al:
- Een gedeeld wachtwoord is voor iedereen identiek. Je kunt niet zien wie het verder heeft gedeeld, en het intrekken ervan gooit alle bezoekers tegelijk eruit — inclusief de klant die middenin een review zit.
- Staging-URL's worden geïndexeerd. Vergeet één
noindex-header en Google vindt hem. "Niet vermeld" is niet hetzelfde als "privé". - Geen van beide verloopt vanzelf. Zes maanden later werkt de link die een voormalige staging-tester van een klant in zijn browsergeschiedenis heeft bewaard nog steeds.
Niets hiervan is een probleem van wachtwoordsterkte. Het zijn identiteitsproblemen — het systeem heeft geen manier om te weten wie de inloggegevens gebruikt, alleen dát de inloggegevens klopten.
Wat een magic link eigenlijk is
Een magic link ruilt "bewijs dat je een geheim kent dat iedereen kent" in voor "bewijs dat je een token bezit dat niemand anders heeft". In Erdo Client Preview is dat token een cryptografisch willekeurige string — lang genoeg dat raden in de praktijk onhaalbaar is —, gegenereerd per persoon, per doel, met een eigen label, vervaltijd en gebruiksteller.
Cruciaal: het ruwe token wordt je maar één keer getoond, bij het aanmaken, in de URL die je kopieert en verstuurt. Het wordt nooit in een leesbare vorm naar de database geschreven.
Waarom HMAC in plaats van gewoon het token opslaan
Dit is het deel dat de meeste uitleg over "magic links" overslaat. Het ruwe token in de database opslaan — zelfs in een kolom waar niemand naar kijkt — creëert hetzelfde risico als platte-tekst-wachtwoorden opslaan: één SQL-injectie of één gelekte databaseback-up verwijderd van elke actieve link die bruikbaar wordt voor een aanvaller.
De oplossing is HMAC (Hash-based Message Authentication Code), gedefinieerd in RFC 2104 en sinds PHP 5 ingebouwd in PHP's hash_hmac()-functie. HMAC combineert een bericht (het token) met een geheime sleutel (uniek voor jouw WordPress-installatie) tot een handtekening — in dit geval HMAC-SHA256.
Wat dat oplevert:
- De database bevat alleen de hash. Een gedumpte
wp_options-tabel of een gelekte back-up geeft een aanvaller een eenrichtings-HMAC-SHA256-digest, geen bruikbare link. - De hash kan niet worden hergebruikt om een ander token te vervalsen. Omdat een overeenkomende HMAC berekenen de geheime sleutel vereist, kan een aanvaller niet van een hash terugrekenen naar een geldig token, en ook geen willekeurig token indienen en geaccepteerd krijgen zonder de sleutel te kennen.
- Verificatie is een eenvoudige herberekening. Wanneer een bezoeker een link opent, berekent de plugin de HMAC van het aangeboden token opnieuw en vergelijkt die met de opgeslagen hash. Bij een match is de link echt; zo niet, dan wordt toegang geweigerd.
De kern: HMAC verandert "heeft de bezoeker de juiste string aangeboden" in "heeft de bezoeker een string aangeboden die alleen de server — en alleen hij, met zijn geheime sleutel — oorspronkelijk kan hebben ondertekend". Dat is een aanzienlijk sterkere garantie dan een platte-tekstvergelijking.
Stap voor stap: van aanmaken tot toegang
- Je klikt in het WordPress-beheerscherm op "Magic link aanmaken". De plugin genereert een willekeurig token en berekent direct de HMAC-SHA256-hash ervan met een geheim dat uniek is voor jouw site.
- Alleen de hash wordt opgeslagen in de database, samen met metadata: een label, een optionele vervaltijd, een optionele redirect en een gebruiksteller. Het ruwe token zit in de URL en wordt nergens anders bewaard.
- Je kopieert de URL en stuurt hem naar wie toegang nodig heeft — een klant, een stakeholder, een reviewer.
- Die persoon opent de link. De plugin haalt het token uit de URL, berekent de HMAC opnieuw en vergelijkt die met de opgeslagen hash.
- Bij een match zet de plugin een ondertekende, HttpOnly-cookie, zodat de bezoeker de hele live site kan doorbladeren zonder op elke pagina opnieuw op de link te klikken. Bij geen match of een verlopen link ziet hij alleen de afgeschermde onderhouds- of "binnenkort"-pagina.
- Je trekt hem op elk moment in — precies die ene link direct ongeldig maken, zonder andere actieve links aan te raken.
Magic links versus de alternatieven
| Aanpak | Toegang per persoon | Overleeft een DB-lek | Individueel intrekbaar | Opzetmoeite |
|---|---|---|---|---|
| Gedeeld paginawachtwoord | Nee — één wachtwoord voor iedereen | Nee — platte-tekst-equivalent, één reset sluit iedereen buiten | Nee | Laag |
| Niet-vermelde staging-URL | Nee — één URL voor iedereen | N.v.t. — geen authenticatie | Nee (URL moet veranderen) | Laag |
| Magic link (HMAC-geverifieerd) | Ja — één token per persoon | Ja — alleen een hash wordt opgeslagen | Ja — per link | Laag (door plugin beheerd) |
Wil je dit specifiek vergelijken met de ingebouwde wachtwoordbeveiliging van WordPress? Die vergelijking hebben we uitgebreider behandeld in Met wachtwoord beveiligde pagina's versus veilige preview-links.
Waarom dit belangrijker is dan het lijkt voor klantwerk
Bureaus en freelancers hebben niet zomaar enige toegangscontrole nodig — ze moeten weten wie wat heeft bekeken, wanneer het stopt met werken, en dat het intrekken van de toegang van één klant nooit die van een ander raakt. Een inloggegeven per persoon, individueel intrekbaar en individueel verlopend, is het enige model dat alle drie levert. Een gedeeld wachtwoord levert er geen van.
Dit verklaart ook waarom magic links zo natuurlijk samengaan met functies als bezoekersfeedback en live annotaties op elementniveau: zodra je weet welk token de site heeft geopend, weet je ook van welke klant een bepaalde annotatie afkomstig is, zonder eerst om een account te vragen.
Bekijk het in de code, niet alleen in deze post
Erdo Client Preview is open source, dus je hoeft niets van het bovenstaande zomaar aan te nemen. Tokengeneratie en HMAC-verificatie staan in de GitHub-repository van de plugin — lees de broncode, open een issue, of stuur een pull request als je iets ziet dat beter kan.
Tot slot
Een magic link is alleen zo betrouwbaar als wat er na het aanmaken met het token gebeurt. Het als platte tekst opslaan maakt van je database een lijst met bruikbare inloggegevens; het als HMAC-SHA256-hash opslaan maakt van een lek een lijst met digests die nutteloos zijn zonder de geheime sleutel die ze heeft geproduceerd. Een klein implementatiedetail met een onevenredig groot effect op wat een worstcase databaselek je uiteindelijk echt kost.
Installeer Erdo Client Preview gratis vanuit WordPress.org en genereer je eerste magic link in minder dan een minuut.