Er TOTP på same berbare datamaskin verkeleg ein andre faktor?

Logg på ein VPN-klient som først ber om eit passord og deretter ein sekssifra kode, og to førespurnader ser ut som to uavhengige barrierar. Telde etter faktortype er dei det: passordet er noko du veit, koden er noko du har. Telde etter kva éin kompromittert berbar datamaskin avdekkjer, kan dei falle saman til éi grense, fordi det du har, er ei fil på maskina du skriv på. Skilnaden mellom dei to teljingane er temaet for denne gjennomgangen.

Følg éi pålogging frå passordfeltet til kodefeltet

Sjå på sekvensen, ikkje etikettene. Klienten sender passordet, tenaren svarar at eit andre prov er kravt, og klienten opnar eit felt for seks eller åtte siffer. Bak det feltet sit ein generatorapplikasjon med ein delt hemmelegheit og ei klokke. Han reknar ut ein verdi frå hemmelegheiten og det gjeldande tidstrinnet, og tenaren reknar ut den same verdien på nytt frå sin kopi av hemmelegheiten.

Begge sider har det same nøkkelmaterialet. Den symmetrien er den delen folk overser når dei skildrar koden som ein hemmelegheit: leverandøren kan òg generere kodane dine, og difor er frøet meir verdt enn kva som helst einskild utdata. Ein kode som lek er ein eingongsverdi; frøet som produserte han, er ei permanent påloggingsinformasjon som held fram med å produsere gyldige verdiar til det blir erstatta.

Aktivering er den andre halvdelen av flyten. Ein generator som låser seg opp med einingskoden, ein biometrisk førespurnad eller ein kryptert behaldar, viser eit eigedelsprov pluss noko anna. Ein som køyrer ukryptert og låser seg opp med økta til operativsystemet, viser berre fila. Den same applikasjonen kan tilby båe ordningane avhengig av korleis registreringa vart gjord, så avgjerda om utrulling ligg i det trinnet, ikkje på marknadsføringssida til appen.

Avgjer kva koden faktisk provar

Språket i standardane er uvanleg klart her, og verdt å lese direkte. NIST sine retningslinjer om autentikatorar listar opp programvarebaserte OTP-generatorar som autentikatorar, skil mellom eittfaktor-OTP og fleirfaktor-OTP med ein aktiveringsfaktor, og slår fast at OTP-autentisering ikkje er phishing-resistent. Kvar av desse tre setningane endrar kva du kan hevde om førespurnaden.

Ikkje phishing-resistent er den skarpaste kanten. Ein kode som blir skriven i eit felt, kan bli skriven i feltet til ein annan, i sanntid, av ein person som er blitt overtalt til det. Vindauget er kort, noko som reduserer talet på nyttige forsøk, men ikkje lukkar teknikken. Viss kravet ditt omfattar å motstå det, er OTP den gale primitiven, same kvar generatoren køyrer.

Eittfaktor kontra fleirfaktor er den andre skilnaden. Ein kode som viser seg utan eit aktiveringstrinn, provar eigedel av ei fil og ingenting anna, og fila er berre så sterk som kontoen som kan lese henne. Legg til ein aktiveringsfaktor, og påstanden blir betre, sjølv om han framleis skildrar provet som blir lagt fram ved pålogging, ikkje isolasjonen av maskina som produserer det.

Sjå kva ein kompromittert berbar datamaskin kan nå

Ein åtakar med kodekøyring på arbeidsstasjonen er ikkje avgrensa til å lese feltet du skriv i. Økta som blir etablert etter ei vellukka pålogging, er vanlegvis eit token eller ein cookie, og eit token kan brukast frå ei anna maskin heilt utan kode. Viss det er evna du forsvaren deg mot, endrar ein ekstra førespurnad ved pålogging talet på trinn i åtaket, ikkje resultatet.

Les den tredje kolonnen som den ærlege. Kvar ordning over etterlèt noko innanfor tillitsgrensa til arbeidsstasjonen, fordi det er der økta blir brukt. Det som endrar seg, er om den langliva hemmelegheiten reiser med den grensa eller blir utanfor henne, og om provet er bunde til ein bestemd opphav slik at ei etterlikna side ikkje kan videresende det.

To mindre detaljar høyrer til same biletet. Ein kode held seg gyldig i akseptvindauget sitt, ofte tretti sekund pluss toleranse for klokkeavvik, så ein fanga verdi kan spelast av på nytt innanfor det vindauget med mindre verifiseraren nektar gjenbruk. Og installasjon av ein ny generator avsluttar ikkje økter som allereie er autentiserte, så ei forelda økt overlever endringa av påloggingsinformasjon som skulle demme inn hendinga.

Flytt generatoren berre dit skilje hjelper

Å leggje kodegeneratoren på ein telefon er ei reell betring for éin bestemd svikt: ein stolen berbar datamaskin ber ikkje lenger båe prova. Det gjer ingenting mot øktkapring på den berbare, ingenting for ein brukar som skriv ein kode på ei phishing-side, og ingenting for gjenopprettingskodane som vart skrivne ut éin gong og fotograferte inn i ein notatapp.

Skriv difor kravet før du vel verktøyet. Viss målet er eit ekstra prov mot eit lekt passord, sei det rett ut, og appen på same eining leverer det allereie. Viss målet er motstandskraft mot kompromittering av VPN-arbeidsstasjonen, nemn den åtakarevna og vel ei ordning som er vurdert for henne, med phishing-kravet oppgjeve separat i staden for antatt.

Deretter handsamar du den operasjonelle halvdelen, som avgjer om noko av dette overlever kontakt med ei hending. Tap av eining krev ein dokumentert utskiftingsveg, rotasjon av påloggingsinformasjon krev tilbakekalling av aktive økter, og registreringsmateriale krev same vern som frøet, sidan ein uverna registreringskopi gir ein åtakar dei same framtidige kodane på ein kortare veg. Å ramse opp dei fire punkta er meir nyttig enn å diskutere om tokens på same eining er gode eller verdilause.