Är TOTP på samma laptop verkligen en andra faktor?
En kodgenerator på VPN-laptopen är en innehavsfaktor som ligger inom samma komprometteringsgräns. Följ först fröet och sessionen.
Logga in på en VPN-klient som först begär ett lösenord och sedan en sexsiffrig kod, och två uppmaningar ser ut som två oberoende barriärer. Räknat efter faktortyp är de det: lösenordet är något du vet, koden är något du har. Räknat efter vad en enda komprometterad laptop avslöjar kan de falla samman till en enda gräns, eftersom det du har är en fil på maskinen du skriver på. Skillnaden mellan de två räkningarna är ämnet för den här genomgången.
Följ en inloggning från lösenordsfältet till kodfältet
Titta på sekvensen, inte på etiketterna. Klienten skickar lösenordet, servern svarar att ett andra bevis krävs, och klienten öppnar ett fält för sex eller åtta siffror. Bakom det fältet sitter en generatorapplikation med en delad hemlighet och en klocka. Den beräknar ett värde från hemligheten och det aktuella tidssteget, och servern räknar om samma värde från sin kopia av hemligheten.
Båda sidor har samma nyckelmaterial. Den symmetrin är den del folk missar när de beskriver koden som en hemlighet: leverantören kan också generera dina koder, och därför är fröet värt mer än någon enskild utdata. En kod som läcker är ett engångsvärde; fröet som producerade den är en permanent inloggningsuppgift som fortsätter att producera giltiga värden tills det byts ut.
Aktivering är den andra halvan av flödet. En generator som låses upp med enhetskoden, en biometrisk uppmaning eller en krypterad behållare visar ett innehavsbevis plus något annat. En som kör okrypterat och låses upp med operativsystemets session visar bara filen. Samma applikation kan erbjuda båda arrangemangen beroende på hur registreringen gjordes, så driftsättningsbeslutet ligger i det steget, inte på appens marknadsföringssida.
Avgör vad koden faktiskt bevisar
Språket i standarderna är ovanligt klart här, och värt att läsa direkt. NIST:s vägledning om autentiserare listar programvarubaserade OTP-generatorer som autentiserare, skiljer enfaktor-OTP från flerfaktor-OTP med en aktiveringsfaktor, och anger att OTP-autentisering inte är phishingresistent. Var och en av de tre satserna ändrar vad du kan hävda om uppmaningen.
Att inte vara phishingresistent är den skarpaste kanten. En kod som skrivs i ett fält kan skrivas i någon annans fält, i realtid, av en person som övertalats att göra det. Fönstret är kort, vilket minskar antalet användbara försök men stänger inte tekniken. Om ditt krav omfattar att stå emot det är OTP den felaktiga primitiven, oavsett var generatorn kör.
Enfaktor kontra flerfaktor är den andra skillnaden. En kod som visas utan ett aktiveringssteg bevisar innehav av en fil och inget annat, och filen är bara så stark som kontot som kan läsa den. Lägg till en aktiveringsfaktor och påståendet blir bättre, även om det fortfarande beskriver beviset som läggs fram vid inloggning, inte isoleringen av maskinen som producerar det.
Se vad en komprometterad laptop kan nå
En angripare med kodkörning på arbetsstationen är inte begränsad till att läsa fältet du skriver i. Sessionen som upprättas efter en lyckad inloggning är vanligtvis en token eller en kaka, och en token kan användas från en annan maskin helt utan kod. Om det är förmågan du försvarar dig mot ändrar en extra uppmaning vid inloggning antalet steg i attacken, inte resultatet.
| Arrangement | What it adds at login | What it leaves inside the laptop boundary |
|---|---|---|
| Password plus TOTP app on the same machine | A possession proof the password alone does not supply | The seed, the unlock step and the authenticated session |
| TOTP app on a separate phone | Seed storage outside the workstation | Session cookies, the typed password and any prompt that can be proxied |
| Hardware key with a signed challenge | A per-login signature bound to the origin | Whatever the browser and the workstation are already trusted to do |
Läs den tredje kolumnen som den ärliga. Varje arrangemang ovan lämnar något inom arbetsstationens förtroendegräns, eftersom det är där sessionen används. Det som förändras är om den långlivade hemligheten reser med den gränsen eller stannar utanför den, och om beviset är bundet till ett specifikt ursprung så att en efterliknad sida inte kan vidarebefordra det.
Två mindre detaljer hör till samma bild. En kod förblir giltig under sitt acceptansfönster, ofta trettio sekunder plus tolerans för klockavvikelse, så ett fångat värde kan spelas upp igen inom det fönstret om inte verifieraren vägrar återanvändning. Och att installera en ny generator avslutar inte sessioner som redan är autentiserade, så en föråldrad session överlever bytet av inloggningsuppgift som skulle ha begränsat incidenten.
Flytta generatorn bara dit där separationen hjälper
Att lägga kodgeneratorn på en telefon är en verklig förbättring för ett specifikt fel: en stulen laptop bär inte längre båda bevisen. Det gör ingenting mot sessionskapning på laptopen, ingenting för en användare som skriver in en kod på en phishing-sida, och ingenting för återställningskoderna som skrevs ut en gång och fotograferades in i en anteckningsapp.
Skriv därför kravet innan du väljer verktyget. Om målet är ett extra bevis mot ett läckt lösenord, säg det rakt ut, och appen på samma enhet levererar det redan. Om målet är motståndskraft mot kompromettering av VPN-arbetsstationen, namnge den angriparkapaciteten och välj ett arrangemang som är bedömt för den, med phishing-kravet angivet separat i stället för antaget.
Ta sedan hand om den operativa halvan, som avgör om något av detta överlever kontakt med en incident. Förlust av enhet kräver en dokumenterad utbytesväg, rotation av inloggningsuppgifter kräver att aktiva sessioner återkallas, och registreringsmaterial kräver samma skydd som fröet, eftersom en oskyddad registreringskopia ger en angripare samma framtida koder via en kortare väg. Att räkna upp de fyra punkterna är mer användbart än att diskutera om tokens på samma enhet är bra eller värdelösa.