Varför skydda ett lösenord när man kan avstå från det?

Ett problem som vi har vant oss vid att betrakta som normalt

Praktiskt taget alla webbapplikationer har en administrationspanel. Och en administrationspanel har i regel en inloggningsadress, ett autentiseringsformulär, ett användarnamn och ett lösenord.

Vi har vant oss så mycket vid den här konstruktionen att vi nästan har slutat fråga oss: måste allt verkligen fungera just så?

När man bara har en webbplats känns problemet inte särskilt stort. Man skapar ett starkt lösenord, aktiverar tvåfaktorsautentisering, begränsar antalet inloggningsförsök – och arbetar vidare.

Men vad händer när projekten blir tio, tjugo eller trettio?

I mitt fall handlar det om DigiMeld-ekosystemet, som omfattar mer än trettio fristående programvaruprojekt. Var och en har sin egen arkitektur, serverlogik och sitt eget administrationsgränssnitt.

Följaktligen behöver varje projekt en mekanism för administrativ åtkomst.

Länge använde jag ett ganska traditionellt tillvägagångssätt: separata administrativa inloggningsuppgifter, starka lösenord och lagring av dem i webbläsaren.

Det fungerade.

Men vid ett tillfälle började jag fundera: varför ska jag över huvud taget lagra så många administrativa lösenord? Varför måste jag skydda inte bara servrarna, utan också själva verktygen som ger åtkomst till dem?

Och går det att slippa det behovet?

Jag kom fram till en tanke som senare blev grunden för min lösning:

Det kanske är bättre att skydda rätten att få tillfällig åtkomst än en permanent inloggningsväg.

Tänk om den vanliga inloggningssidan inte fanns alls?

Jag bestämde mig för att överge den traditionella modellen för administrativ autentisering i mina projekt.

Inte bara gömma inloggningsformuläret.

Inte byta namn på adressen.

Inte ersätta lösenordet med ett ännu starkare lösenord.

Utan att ta bort själva behovet av en permanent lösenordsbaserad inloggning.

Självklart försvann inte administrationsgränssnitten. De behövs fortfarande för att hantera applikationerna.

Det som förändrades var hur man får åtkomst till dem.

Nu behöver jag inte ange ett sparat användarnamn och lösenord för att logga in på administrationspanelerna för anslutna projekt.

I stället använder jag mitt eget system för identitets- och åtkomsthantering, MeldID.

Grundtanken är enkel: administrativ åtkomst beviljas bara när den faktiskt behövs, till en specifik användare och för ett specifikt projekt.

Att ett konto finns innebär inte i sig att man har rätt att öppna administrationspanelen.

Den behörigheten måste beviljas separat.

Åtkomst som inte fanns för en minut sedan

Det här är kanske den mest intressanta delen av hela konceptet.

I den traditionella modellen har administratören hela tiden inloggningsuppgifter till sitt förfogande. De kan användas i dag, i morgon eller om en månad, så länge de fortfarande är giltiga.

Jag bestämde mig för att ändra den principen.

I stället för permanenta administrativa inloggningsuppgifter används en tillfällig möjlighet att initiera en inloggning.

Den skapas på begäran via en betrodd mobil enhet, innehåller en kryptografiskt stark slumpmässig komponent och har en begränsad giltighetstid.

Men att bara ha den tillfälliga länken innebär inte i sig att man får åtkomst.

Det är en avgörande detalj.

Anta att någon på något sätt får tag på länken. I ett vanligt system som enbart bygger på att adressen hålls hemlig skulle en sådan läcka kunna bli ett allvarligt problem.

I min modell gör länken det bara möjligt att inleda en bekräftelseprocess.

För att gå vidare krävs ett separat godkännande via en betrodd mobil enhet med MeldID.

Utan motsvarande bekräftelse skapas ingen administrativ session.

Därför betraktar jag inte den tillfälliga länken som en ersättning för lösenordet, utan som en del av processen för att bevilja åtkomst.

Att veta vart man ska vända sig och att ha rätt att logga in är två helt olika saker.

Telefonen blir ett verktyg för åtkomsthantering

I den här modellen spelar den mobila enheten en betydligt viktigare roll än en vanlig generator för engångskoder.

Den används för att bekräfta åtgärder som rör administrativ åtkomst.

När jag vill öppna administrationspanelen begär systemet en bekräftelse via MeldID.

Jag ser motsvarande begäran på den betrodda enheten och godkänner åtgärden.

Först efter en lyckad kontroll låter systemet mig fortsätta inloggningsprocessen.

Bekräftelsen är kopplad till en specifik åtgärd, inte bara till att telefonen har låsts upp.

Mobilbiometri verifierar användaren lokalt, medan serversidan kontrollerar den kryptografiska bekräftelsen från den registrerade enheten.

Med det här tillvägagångssättet behöver man inte enbart förlita sig på ett lösenord eller på ett meddelande om att användaren påstås ha bekräftat inloggningen.

Här uppstår ytterligare en fördel: det går att hantera betrodda enheter.

Om en enhet inte längre ska användas för att bekräfta åtkomst kan dess betrodda status återkallas.

Därefter upphör den att vara ett giltigt autentiseringsmedel för de berörda åtgärderna.

Ett system – många självständiga projekt

När jag började utveckla den här mekanismen var en av de viktigaste uppgifterna att bevara varje projekts självständighet.

Jag ville inte slå ihop alla administrationspaneler till en enda stor applikation.

Varje DigiMeld-tjänst ska fortfarande hantera sin egen logik, sina egna inställningar, användare och data.

Därför delade jag upp de två uppgifterna.

MeldID ansvarar för identitetsverifiering och beviljande av administrativ åtkomst.

Själva projektet ansvarar för sina egna administrativa funktioner och för att kontrollera att behörigheterna fortfarande gäller.

Resultatet blev en centraliserad modell för åtkomsthantering utan att själva applikationerna behövde centraliseras.

Dessutom beviljas behörigheter separat.

En administratör för ett projekt får inte automatiskt åtkomst till de andra bara för att hen har ett MeldID-konto.

För varje administrativt område går det att ange en egen grupp av behöriga användare.

Samtidigt hålls vanliga användarbehörigheter åtskilda från administrativa rättigheter.

Det visade sig vara särskilt praktiskt för ett ekosystem med dussintals tjänster.

Varför jag föredrar tillfällig framför permanent åtkomst

Det finns ytterligare en princip som jag medvetet byggde in i systemet.

Administrativ åtkomst ska inte finnas kvar för alltid.

Behörigheten gäller under en begränsad tid och upphör oavsett om användaren fortsätter arbeta i webbläsaren eller inte.

För att fortsätta arbeta efter att giltighetstiden har löpt ut krävs en ny bekräftelseprocess.

Det gör att en genomförd autentisering inte förvandlas till en permanent giltig behörighet.

Men en tidsbegränsning räcker inte i sig.

Det är viktigt att kunna avsluta åtkomst som redan har beviljats i förtid.

Därför har MeldID en central funktion för att återkalla administrativa behörigheter.

När en behörighet återkallas får de anslutna projekten en motsvarande händelse och ogiltigförklarar de administrativa sessioner som hör till den.

På så sätt upphör inte åtkomsthanteringen i samma ögonblick som användaren har loggat in.

För mig är möjligheten att återkalla behörigheter minst lika viktig som möjligheten att bevilja dem.

Samtidigt måste ett distribuerat system ta hänsyn till fördröjningar i händelseöverföringen, tillfällig otillgänglighet hos enskilda komponenter och andra driftsförhållanden. Sessionernas begränsade giltighetstid utgör en extra säkerhetsgräns.

Vad har förändrats i det dagliga arbetet?

Framför allt har jag inte längre något behov av att hela tiden använda sparade administrativa lösenord.

Jag behöver inte längre lagra en uppsättning inloggningsuppgifter i webbläsaren för varje ansluten administrationspanel.

I stället hanterar jag behörigheterna genom en gemensam mekanism.

Jag väljer det projekt jag behöver, bekräftar åtkomsten och arbetar.

När jag inte längre behöver administrativ åtkomst kan den återkallas.

Det är särskilt praktiskt att jag inte behöver utforma hela systemet för administrativ autentisering på nytt när ett nytt projekt tillkommer.

Det räcker att ansluta projektet till den befintliga modellen och ange de behörigheter som behövs.

Självklart betyder det inte att alla säkerhetsrisker har försvunnit.

Tillfälliga behörigheter, betrodda enheter, serversessioner och den centrala infrastrukturen behöver också skyddas.

Men jag behöver inte längre lösa samma problem med hantering av administrativa lösenord separat för varje applikation.

Och det var just ett av mina ursprungliga mål.

Finns inte sådana tekniker redan?

Jo, det gör de.

Lösenordsfri autentisering, hantering av privilegierad åtkomst, tillfälliga behörigheter och bekräftelse via betrodda enheter är sedan länge välkända inom informationssäkerhetsbranschen.

Sådana metoder förekommer i system för Identity and Access Management, Privileged Access Management och i Zero Trust-koncept.

Jag gör inte anspråk på att ha uppfunnit de här principerna.

Mitt mål var ett annat.

Jag behövde skapa ett eget, integrerat system som löser specifika problem i DigiMelds infrastruktur och gör det möjligt att hantera administrativ åtkomst till många självständiga projekt.

Resultatet blev att jag kombinerade flera välkända metoder i en arkitektur som uppfyller mina krav.

Jag anser att värdet av ingenjörsarbete inte nödvändigtvis ligger i att uppfinna en helt ny teknik.

Ibland ligger det i att formulera problemet på rätt sätt och hitta en lösning som passar.

MeldID är till för mer än administrationspaneler

Här är det värt att göra ett särskilt förtydligande.

MeldID skapades inte enbart som ett verktyg för min egen administrativa åtkomst.

Systemet tillhandahåller också ett SDK för utvecklare som vill integrera funktioner för identitetsverifiering och inloggningsbekräftelse i sina egna applikationer.

SDK:t är dessutom gratis.

En extern utvecklare kan till exempel använda MeldID som ett extra lager för att bekräfta användarautentisering.

Även om applikationen fortfarande har traditionell inloggning med användarnamn och lösenord kan det hända att det inte räcker att ange dessa uppgifter korrekt för att slutföra autentiseringen.

Användaren får då en begäran på en betrodd mobil enhet, där hen kan godkänna eller avvisa inloggningsförsöket.

Det kan minska risken för obehörig åtkomst om inloggningsuppgifterna har komprometterats.

Det är viktigt att skilja den här allmänt tillgängliga funktionen i MeldID från den modell för administrativ åtkomst till DigiMeld-projekten som jag har utvecklat.

De bygger på gemensamma principer för tillit och bekräftelse av åtgärder, men löser olika problem.

Säkerhet handlar inte bara om att skydda det som redan finns

Arbetet med det här systemet fick mig att se på de vanliga autentiseringsmekanismerna på ett annat sätt.

Vi försöker ofta skydda sådant som finns kvar av historiska skäl.

Vi lägger till nya kontroller, begränsningar, extra lösenord och skyddslager.

Ibland är det verkligen nödvändigt.

Men ibland är det mer givande att ställa en annan fråga:

Måste själva mekanismen som vi försöker skydda verkligen finnas kvar i sin nuvarande form?

I mitt fall visade sig svaret vara nej.

Jag behövde inget permanent tillgängligt formulär för administrativ inloggning.

Jag behövde ett säkert sätt att få administrativa behörigheter precis när de behövs.

Det är två olika uppgifter.

Övergången från den första till den andra förändrade både den tekniska arkitekturen och det dagliga arbetet med projekten.

Inte ett slutgiltigt svar, utan en vald riktning

I dag används den här arkitekturen redan i en stor del av DigiMeld-ekosystemet.

De återstående projekten flyttas gradvis över till den nya modellen för administrativ åtkomst.

Jag genomför migreringen stegvis, testar varje applikation och planerar en ytterligare granskning av hela systemet när övergången är klar.

Vissa delar av gränssnittet och reglerna för sessionshantering kan fortfarande komma att ändras.

Men grundidén är redan fastställd.

Jag vill inte återgå till en modell där jag måste lagra och använda dussintals administrativa lösenord för att hantera dussintals egna projekt.

Samtidigt anser jag inte att min lösning är universell.

Olika organisationer har olika krav, infrastruktur, hotmodeller och sätt att administrera sina system.

Det som är praktiskt och motiverat för DigiMeld-ekosystemet är inte nödvändigtvis det bästa valet för en annan utvecklare.

Men principen att bevilja behörigheter tillfälligt är värd att uppmärksamma.

Avslutningsvis

Jag bestämde mig för att dela med mig av den här erfarenheten inte för att jag ser mig själv som uppfinnaren av en ny autentiseringsmetod.

Och inte för att jag vill framställa ännu ett system som helt säkert.

Absolut säkerhet finns inte.

Jag tycker helt enkelt att själva frågeställningen är intressant.

I stället för att i all oändlighet skydda en permanent administrativ inloggning kan man ompröva om den behöver finnas över huvud taget.

I stället för att lagra en mängd lösenord kan man använda tillfälliga behörigheter.

I stället för att automatiskt lita på en användare efter den första autentiseringen kan man bekräfta att specifika behörigheter beviljas.

I stället för att bara vänta på att sessionen ska löpa ut kan man införa en möjlighet att återkalla åtkomsten centralt.

Och slutligen kan man i stället för en separat inloggningsmekanism i varje projekt bygga ett gemensamt system för att hantera administrativ åtkomst och samtidigt bevara applikationernas självständighet.

Jag påstår inte att det här tillvägagångssättet eliminerar risken för kompromettering.

Det flyttar helt enkelt fokus från att skydda permanent existerande inloggningsuppgifter till att kontrollera hur behörigheter beviljas och återkallas.

Ibland är kanske det effektivaste sättet att minska attackytan inte att lägga till ännu en skyddsmekanism, utan att avstå från något som systemet faktiskt kan fungera utan.

Det var just den tanken som blev början på historien om MeldID Admin Gateway för mig.