Waarom een wachtwoord beveiligen als je het ook kunt afschaffen?

Een probleem dat we als normaal zijn gaan beschouwen

Vrijwel elke webapplicatie heeft een beheerderspaneel. En een beheerderspaneel heeft doorgaans een inlogadres, een aanmeldformulier, een gebruikersnaam en een wachtwoord.

We zijn zo gewend geraakt aan deze constructie dat we ons bijna niet meer afvragen: moet alles eigenlijk wel op deze manier werken?

Als je één website hebt, lijkt het probleem niet zo groot. Je maakt een sterk wachtwoord aan, schakelt tweefactorauthenticatie in, stelt een limiet in voor het aantal inlogpogingen — en gaat aan het werk.

Maar wat gebeurt er als je tien, twintig of dertig projecten hebt?

In mijn geval gaat het om het DigiMeld-ecosysteem, dat meer dan dertig zelfstandige softwareprojecten omvat. Elk project heeft een eigen architectuur, serverlogica en beheerinterface.

En dus heeft elk project een mechanisme voor beheerderstoegang nodig.

Lange tijd gebruikte ik een heel gebruikelijke aanpak: afzonderlijke beheerdersaccounts, sterke wachtwoorden en die wachtwoorden opslaan in de browser.

Dat werkte.

Maar op een gegeven moment vroeg ik me af: waarom moet ik eigenlijk zoveel beheerderswachtwoorden bewaren? Waarom moet ik niet alleen de servers beveiligen, maar ook de middelen waarmee ik toegang daartoe krijg?

En kan ik daar niet helemaal van afzien?

Ik kwam op een gedachte die later de basis van mijn oplossing werd:

Misschien moeten we niet de permanente toegang beveiligen, maar het recht om tijdelijk toegang te krijgen.

Een sterk wachtwoord lost het onderliggende probleem niet op

Met moderne hulpmiddelen kun je wachtwoorden met een zeer hoge entropie aanmaken. Een correct gegenereerd, lang en willekeurig wachtwoord is praktisch onmogelijk te raden met een brute-forceaanval.

Maar hoe sterk het wachtwoord ook is, je moet het ergens bewaren en vervolgens gebruiken.

Je kunt wachtwoordmanagers, hardwaresleutels, multifactorauthenticatie en aanvullende beperkingen gebruiken. Dat alles verhoogt de veiligheid daadwerkelijk.

Maar de architectuur blijft hetzelfde: er is een bepaalde interface waarlangs de gebruiker zijn inloggegevens opgeeft.

Die interface kan worden aangevallen. Ze kan worden gescand. Ze kan het doelwit worden van geautomatiseerde aanvallen.

Je kunt het adres van het beheerderspaneel verbergen, het standaardpad vervangen door een lange, willekeurige tekenreeks of de toegang beperken op basis van IP-adres.

Maar dan rijst een nieuwe vraag: waar bewaar je dat adres en hoe gebruik je het?

En vooral: waarom zou je een permanent toegangspunt behouden als je alleen op bepaalde momenten beheerders toegang nodig hebt?

Ik kwam tot een gedachte die later de basis van mijn oplossing werd:

Misschien moeten we niet de permanente toegang beveiligen, maar het recht om tijdelijk toegang te krijgen.

Wat als er helemaal geen vertrouwde inlogpagina is?

Ik besloot in mijn projecten af te stappen van het traditionele model voor beheerderauthenticatie.

Niet alleen het inlogformulier verbergen.

Niet alleen het adres wijzigen.

Niet een nog ingewikkelder wachtwoord gebruiken.

Maar de noodzaak van een permanent beschikbare wachtwoordinlog helemaal wegnemen.

Natuurlijk zijn de beheerinterfaces niet verdwenen. Ze zijn nog steeds nodig om de applicaties te beheren.

De manier waarop je toegang ertoe krijgt, is veranderd.

Om in te loggen op de beheerderspanelen van aangesloten projecten hoef ik nu geen opgeslagen gebruikersnaam en wachtwoord meer in te voeren.

In plaats daarvan gebruik ik mijn eigen systeem voor identiteits- en toegangsbeheer: MeldID.

Het idee is eenvoudig: beheertoegang wordt alleen verleend wanneer die daadwerkelijk nodig is, aan een specifieke gebruiker en voor een specifiek project.

Het bestaan van een account betekent op zichzelf nog niet dat iemand het recht heeft om het beheerderspaneel te openen.

Dat recht moet afzonderlijk worden verleend.

Toegang die er een minuut geleden nog niet was

Dit is waarschijnlijk het interessantste onderdeel van het hele concept.

In het traditionele model beschikt een beheerder voortdurend over inlogmiddelen. Hij kan die vandaag, morgen of over een maand gebruiken, zolang ze geldig blijven.

Ik besloot dat principe te veranderen.

In plaats van permanente beheerdersgegevens is er een tijdelijke mogelijkheid om een inlogprocedure te starten.

Die wordt op verzoek aangemaakt via een vertrouwd mobiel apparaat, bevat een cryptografisch sterke willekeurige component en is maar een beperkte tijd geldig.

Maar zelfs het bezit van zo'n tijdelijke link geeft op zichzelf nog geen toegang.

Dat is een belangrijk onderscheid.

Stel dat iemand op de een of andere manier de link heeft verkregen. In een systeem dat uitsluitend op de geheimhouding van het adres is gebaseerd, zou zo'n lek een serieus probleem kunnen vormen.

In mijn model dient de link alleen om de bevestigingsprocedure te starten.

Om verder te gaan, is afzonderlijke goedkeuring via een vertrouwd mobiel apparaat met MeldID nodig.

Zonder die bevestiging wordt er geen beheerderssessie aangemaakt.

Daarom beschouw ik de tijdelijke link niet als vervanging van een wachtwoord, maar als één onderdeel van de procedure om toegang te verlenen.

Weten waar je moet aankloppen en het recht hebben om binnen te komen zijn twee heel verschillende dingen.

De telefoon wordt een hulpmiddel voor toegangsbeheer

In dit model speelt het mobiele apparaat een veel belangrijkere rol dan die van een gewone generator voor eenmalige codes.

Het wordt gebruikt om handelingen met betrekking tot beheertoegang te bevestigen.

Wanneer ik het beheerderspaneel wil openen, vraagt het systeem om bevestiging via MeldID.

Ik zie het betreffende verzoek op mijn vertrouwde apparaat en keur de handeling goed.

Pas nadat de controle is geslaagd, laat het systeem de inlogprocedure doorgaan.

De bevestiging is daarbij gekoppeld aan een specifieke handeling, en niet alleen aan het feit dat de telefoon is ontgrendeld.

Biometrische verificatie op het mobiele apparaat controleert de gebruiker lokaal, terwijl de serverzijde de cryptografische bevestiging van het geregistreerde apparaat controleert.

Zo hoef je niet uitsluitend te vertrouwen op een wachtwoord of op een melding dat de gebruiker zogenaamd heeft bevestigd dat hij wil inloggen.

En hier ontstaat nog een voordeel: vertrouwde apparaten kunnen worden beheerd.

Als een apparaat niet langer mag worden gebruikt om toegang te bevestigen, kan de vertrouwde status ervan worden ingetrokken.

Daarna is het niet langer een geldig middel om de betreffende handelingen te autoriseren.

Eén systeem — meerdere onafhankelijke projecten

Toen ik dit mechanisme begon te ontwikkelen, was het behouden van de zelfstandigheid van elk project een van de belangrijkste aandachtspunten.

Ik wilde niet alle beheerderspanelen samenvoegen tot één enorme applicatie.

Elke DigiMeld-service moet zijn eigen logica, instellingen, gebruikers en gegevens blijven beheren.

Daarom heb ik de twee taken van elkaar gescheiden.

MeldID is verantwoordelijk voor de identificatie en het verlenen van beheerdersbevoegdheden.

Het project zelf blijft verantwoordelijk voor zijn eigen beheerfuncties en voor het controleren van de actuele bevoegdheden.

Zo ontstond een gecentraliseerd model voor toegangsbeheer, zonder dat de applicaties zelf gecentraliseerd hoefden te worden.

Daarnaast worden rechten afzonderlijk verleend.

Een beheerder van één project krijgt niet automatisch toegang tot de andere projecten alleen omdat hij een MeldID-account heeft.

Voor elk beheerdersgedeelte kan een eigen groep gebruikers met toegang worden bepaald.

De rechten van gewone gebruikers en de beheerdersbevoegdheden blijven daarbij gescheiden.

Voor een ecosysteem met tientallen services bleek dat bijzonder handig.

Waarom ik tijdelijke toegang verkies boven permanente toegang

Er is nog een principe dat ik bewust in het systeem heb ingebouwd.

Beheertoegang mag niet onbeperkt blijven bestaan.

De toestemming is maar beperkte tijd geldig en verloopt ongeacht of de gebruiker nog met de browser werkt.

Om na afloop verder te werken, is een nieuwe bevestigingsprocedure nodig.

Zo voorkom je dat een eenmalige aanmelding verandert in een permanent geldig recht.

Maar een tijdslimiet alleen is niet voldoende.

Het is belangrijk dat de verleende toegang ook voortijdig kan worden beëindigd.

Daarom biedt MeldID een centrale mogelijkheid om beheerdersrechten in te trekken.

Wanneer een toestemming wordt ingetrokken, ontvangen de aangesloten projecten daarvan een melding en maken ze de bijbehorende beheerderssessies ongeldig.

Toegangsbeheer houdt dus niet op zodra de gebruiker succesvol is ingelogd.

De mogelijkheid om bevoegdheden in te trekken is voor mij minstens zo belangrijk als de mogelijkheid om ze te verlenen.

Een gedistribueerd systeem moet bovendien rekening houden met vertragingen bij het doorgeven van gebeurtenissen, tijdelijke onbeschikbaarheid van afzonderlijke componenten en andere operationele omstandigheden. De beperkte geldigheid van sessies biedt daarbij een extra veiligheidsgrens.

Wat is er veranderd in het dagelijkse werk?

Allereerst hoef ik niet langer voortdurend terug te grijpen op opgeslagen beheerderswachtwoorden.

Ik hoef niet meer voor elk aangesloten beheerderspaneel in de browser een set inloggegevens te bewaren.

In plaats daarvan beheer ik de toestemmingen via één mechanisme.

Ik kies het gewenste project, bevestig de toegang en ga aan het werk.

Wanneer beheertoegang niet meer nodig is, kan ik die intrekken.

Het is vooral handig dat er bij de komst van een nieuw project geen volledig nieuw systeem voor beheerderauthenticatie hoeft te worden ontworpen.

Het volstaat om het project aan het bestaande model te koppelen en de benodigde rechten vast te leggen.

Dat betekent natuurlijk niet dat alle beveiligingsrisico's zijn verdwenen.

Tijdelijke toestemmingen, vertrouwde apparaten, serversessies en centrale infrastructuur moeten ook worden beveiligd.

Maar ik hoef niet langer voor elke applicatie afzonderlijk hetzelfde probleem van het beheer van beheerderswachtwoorden op te lossen.

En dat was precies een van mijn oorspronkelijke doelen.

Bestaan dit soort technologieën niet al?

Natuurlijk wel.

Wachtwoordloze authenticatie, beheer van geprivilegieerde toegang, tijdelijke toestemmingen en bevestiging via vertrouwde apparaten zijn al lang bekend in de informatiebeveiligingssector.

Dit soort aanpakken komt voor in Identity and Access Management-systemen, Privileged Access Management en Zero Trust-concepten.

Ik beweer niet dat ik deze principes heb uitgevonden.

Mijn opdracht was een andere.

Ik moest een eigen, geïntegreerd systeem opzetten dat de specifieke problemen van de DigiMeld-infrastructuur oplost en beheer van toegang tot meerdere zelfstandige projecten mogelijk maakt.

Uiteindelijk heb ik verschillende bekende aanpakken samengebracht in één architectuur die aan mijn eisen voldoet.

Ik vind dat de waarde van technisch werk niet per se ligt in het uitvinden van een volledig nieuwe technologie.

Soms draait het erom het probleem goed te formuleren en er een passende oplossing voor te vinden.

MeldID is er niet alleen voor beheerderspanelen

Hierbij is een aparte toelichting op zijn plaats.

MeldID is niet uitsluitend ontwikkeld als hulpmiddel voor mijn eigen beheerderstoegang.

Het biedt ontwikkelaars ook een SDK om identiteits- en inlogbevestigingsmechanismen in hun eigen applicaties te integreren.

Die SDK is bovendien gratis beschikbaar.

Een externe ontwikkelaar kan MeldID bijvoorbeeld gebruiken als extra bevestigingslaag voor gebruikersauthenticatie.

Zelfs als een applicatie de traditionele aanmelding met gebruikersnaam en wachtwoord behoudt, hoeft het invoeren van die gegevens niet voldoende te zijn om de aanmelding af te ronden.

De gebruiker ontvangt een verzoek op een vertrouwd mobiel apparaat, waar hij de inlogpoging kan goedkeuren of afwijzen.

Zo wordt het risico op ongeoorloofde toegang bij gecompromitteerde inloggegevens kleiner.

Het is belangrijk om deze openbare functionaliteit van MeldID te onderscheiden van het model voor beheertoegang dat ik voor de DigiMeld-projecten heb ontwikkeld.

Ze zijn gebaseerd op dezelfde principes van vertrouwen en bevestiging van handelingen, maar lossen verschillende problemen op.

Beveiliging gaat niet alleen over beschermen wat er al is

Het werk aan dit systeem heeft me anders laten kijken naar de vertrouwde mechanismen voor authenticatie.

Vaak proberen we iets te beveiligen dat om historische redenen bestaat.

We voegen controles, beperkingen, extra wachtwoorden en beveiligingslagen toe.

Soms is dat inderdaad nodig.

Maar soms is het nuttiger om een andere vraag te stellen:

Moet het mechanisme dat we beveiligen eigenlijk wel in zijn huidige vorm blijven bestaan?

In mijn geval was het antwoord nee.

Ik had geen permanent beschikbaar aanmeldformulier voor beheerders nodig.

Ik had een manier nodig om veilig beheerdersbevoegdheden te verkrijgen, precies wanneer dat nodig is.

Dat zijn twee verschillende problemen.

De overstap van het eerste naar het tweede veranderde niet alleen de technische architectuur, maar ook de dagelijkse manier waarop ik met de projecten werk.

Geen eindpunt, maar een gekozen richting

Deze architectuur wordt inmiddels gebruikt in een aanzienlijk deel van het DigiMeld-ecosysteem.

De resterende projecten worden geleidelijk overgezet op het nieuwe model voor beheertoegang.

Ik voer de migratie stapsgewijs uit en controleer de werking van elke applicatie. Na afronding van de overstap plan ik een aanvullende audit van het hele systeem.

Afzonderlijke onderdelen van de interface en regels voor sessiebeheer kunnen nog veranderen.

Maar het basisidee staat vast.

Ik wil niet terug naar een model waarin ik voor het beheren van tientallen eigen projecten voortdurend tientallen beheerderswachtwoorden moet bewaren en gebruiken.

Tegelijkertijd beschouw ik mijn implementatie niet als een universele oplossing voor iedereen.

Organisaties verschillen in hun eisen, infrastructuur, dreigingsmodellen en manieren van beheren.

Wat handig en passend is voor het DigiMeld-ecosysteem, is niet noodzakelijk de beste keuze voor een andere ontwikkelaar.

Het principe van tijdelijke bevoegdheden verdient echter aandacht.

Tot slot

Ik besloot deze ervaring te delen, niet omdat ik mezelf zie als de uitvinder van een nieuwe authenticatiemethode.

En ook niet omdat ik dit systeem als absoluut veilig wil presenteren.

Absolute veiligheid bestaat niet.

Ik vind vooral de manier waarop de vraag wordt gesteld interessant.

In plaats van de permanente toegang voor beheerders eindeloos te beveiligen, kun je opnieuw bekijken of die wel nodig is.

In plaats van een groot aantal wachtwoorden te bewaren, kun je tijdelijke toestemmingen gebruiken.

In plaats van na de eerste aanmelding automatisch vertrouwen te geven, kun je het verlenen van specifieke bevoegdheden bevestigen.

In plaats van te wachten tot een sessie afloopt, kun je voorzien in de mogelijkheid om toegang centraal in te trekken.

En ten slotte kun je, in plaats van voor elk project een apart inlogmechanisme te bouwen, één systeem voor het beheer van toegang voor beheerders opzetten en tegelijk de zelfstandigheid van de applicaties behouden.

Ik beweer niet dat deze aanpak het risico op een compromittering uitsluit.

Ze verlegt simpelweg de nadruk: niet langer naar het beveiligen van permanent bestaande inloggegevens, maar naar het gecontroleerd verlenen en beëindigen van bevoegdheden.

Misschien is het soms het effectiefst om het aanvalsoppervlak te verkleinen door niet nóg een beveiligingsmechanisme toe te voegen, maar afstand te doen van iets waar het systeem prima zonder kan.

Met die gedachte begon voor mij het verhaal van MeldID Admin Gateway.