Is TOTP op dezelfde laptop echt een tweede factor?

Log in bij een VPN-client die eerst een wachtwoord en dan een zescijferige code vraagt, en twee prompts lijken op twee onafhankelijke barrières. Naar factortype geteld zijn ze dat: het wachtwoord is iets wat je weet, de code is iets wat je bezit. Naar wat één gecompromitteerde laptop blootlegt geteld, kunnen ze samenvallen tot één grens, omdat wat je bezit een bestand is op de machine waarin je typt. Het gat tussen die twee tellingen is het onderwerp van deze uiteenzetting.

Volg één login van het wachtwoordveld tot het codeveld

Let op de volgorde, niet op de labels. De client stuurt het wachtwoord, de server antwoordt dat een tweede bewijs nodig is, en de client opent een veld voor zes of acht cijfers. Achter dat veld zit een generatorapplicatie met een gedeeld geheim en een klok. Die berekent een waarde uit het geheim en de huidige tijdstap, en de server herberekent dezelfde waarde uit zijn kopie van het geheim.

Beide kanten houden hetzelfde sleutelmateriaal. Die symmetrie is het deel dat mensen missen wanneer ze de code als een geheim beschrijven: de aanbieder kan jouw codes ook genereren, en daarom is de seed meer waard dan welke afzonderlijke uitvoer dan ook. Een code die uitlekt is een eenmalige waarde; de seed die hem produceerde is een permanente inloggegevens die geldige waarden blijft produceren tot hij wordt vervangen.

Activatie is de andere helft van de stroom. Een generator die ontgrendelt met een apparaatpincode, een biometrisch verzoek of een versleutelde container presenteert een bezitsbewijs plus iets anders. Een die onversleuteld draait en ontgrendelt met de sessie van het besturingssysteem presenteert alleen het bestand. Dezelfde applicatie kan beide regelingen bieden afhankelijk van hoe de inschrijving is gedaan, dus de implementatiebeslissing ligt in die stap, niet op de marketingpagina van de app.

Bepaal wat de code werkelijk bewijst

De taal van de standaarden is hier ongewoon duidelijk, en het loont om die direct te lezen. De richtlijn van NIST voor authenticators noemt softwarematige OTP-generatoren als authenticators, onderscheidt enkelvoudige OTP van meervoudige OTP met een activatiefactor, en stelt dat OTP-authenticatie niet phishingbestendig is. Elk van die drie bepalingen verandert wat je over de prompt kunt beweren.

Niet phishingbestendig zijn is de scherpste rand. Een code die in een veld wordt getypt, kan in iemands anders veld worden getypt, in realtime, door iemand die daartoe is overgehaald. Het venster is kort, wat het aantal bruikbare pogingen vermindert maar de techniek niet sluit. Als je eis het weerstaan daarvan omvat, is OTP de verkeerde primitief, waar de generator ook draait.

Enkelvoudig tegenover meervoudig is het tweede onderscheid. Een code die verschijnt zonder activatiestap bewijst bezit van een bestand en niets anders, en het bestand is slechts zo sterk als het account dat het kan lezen. Voeg een activatiefactor toe en de bewering verbetert, hoewel die nog steeds het bewijs bij de login beschrijft, niet de isolatie van de machine die het produceert.

Zie wat een gecompromitteerde laptop kan bereiken

Een aanvaller met code-uitvoering op de werkstation is niet beperkt tot het lezen van het veld waarin je typt. De sessie die na een geslaagde login tot stand komt is meestal een token of een cookie, en een token kan vanaf een andere machine worden gebruikt zonder enige code. Als dat het vermogen is waartegen je je verdedigt, verandert een tweede prompt bij de login het aantal stappen in de aanval, niet de uitkomst.

Lees de derde kolom als de eerlijke. Elke regeling hierboven laat iets binnen de vertrouwensgrens van de werkstation, omdat de sessie daar wordt gebruikt. Wat verandert is of het langdurige geheim met die grens meereist of erbuiten blijft, en of het bewijs aan een specifieke oorsprong is gebonden zodat een nagebootste pagina het niet kan doorgeven.

Twee kleinere details horen in hetzelfde beeld. Een code blijft geldig gedurende zijn acceptatievenster, vaak dertig seconden plus tolerantie voor klokafwijking, zodat een opgevangen waarde binnen dat venster kan worden herhaald, tenzij de verificateur hergebruik weigert. En het installeren van een nieuwe generator beëindigt geen sessies die al zijn geauthenticeerd, dus een oude sessie overleeft de wijziging van inloggegevens die het incident had moeten indammen.

Verplaats de generator alleen waar scheiding helpt

De codegenerator op een telefoon zetten is een echte verbetering voor één specifiek falen: een gestolen laptop draagt niet langer beide bewijzen. Het doet niets tegen sessiekaping op de laptop, niets voor een gebruiker die een code in een phishingpagina typt, en niets voor de herstelcodes die ooit zijn geprint en gefotografeerd in een notitie-app.

Schrijf dus de eis op voordat je het hulpmiddel kiest. Is het doel een extra bewijs tegen een uitgelekt wachtwoord, zeg dat dan ronduit, en de app op hetzelfde apparaat levert het al. Is het doel weerbaarheid tegen compromittering van de VPN-werkstation, benoem dat aanvallersvermogen en kies een regeling die daarvoor is beoordeeld, met de phishing-eis apart genoemd in plaats van aangenomen.

Behandel daarna de operationele helft, die bepaalt of iets daarvan contact met een incident overleeft. Apparaatverlies vereist een gedocumenteerd vervangingspad, rotatie van inloggegevens vereist het intrekken van actieve sessies, en inschrijvingsmateriaal vereist dezelfde bescherming als de seed, omdat een onbeschermde inschrijvingskopie een aanvaller dezelfde toekomstige codes via een kortere route geeft. Die vier punten opsommen is nuttiger dan discussiëren of tokens op hetzelfde apparaat goed of waardeloos zijn.