É realmente un segundo factor o TOTP no mesmo portátil?
Un xerador de códigos no portátil da VPN é un factor de posesión que queda dentro da mesma fronteira de compromiso. Siga primeiro a semente e a sesión.
Inicie sesión nun cliente VPN que pide un contrasinal e logo un código de seis díxitos, e dous avisos parecen dúas barreiras independentes. Contados por tipo de factor, séno: o contrasinal é algo que sabe, o código é algo que posúe. Contados polo que expón un só portátil comprometido, poden colapsar nunha soa fronteira, porque o que posúe é un ficheiro na máquina na que escribe. A fenda entre esas dúas contas é o tema deste percorrido.
Siga un inicio de sesión desde o campo do contrasinal ata a caixa do código
Observe a secuencia, non as etiquetas. O cliente envía o contrasinal, o servidor responde que fai falta unha segunda proba, e o cliente abre un campo para seis ou oito díxitos. Detrás dese campo hai unha aplicación xeradora que garda un segredo compartido e un reloxo. Calcula un valor a partir do segredo e do paso de tempo actual, e o servidor recalcula o mesmo valor a partir da súa copia do segredo.
Ambos os lados gardan o mesmo material de clave. Esa simetría é a parte que a xente pasa por alto cando describe o código como un segredo: o provedor tamén pode xerar os seus códigos, e por iso a semente vale máis que calquera saída individual. Un código que se filtra é un valor dun só uso; a semente que o produciu é unha credencial permanente que segue producindo valores válidos ata que se substitúe.
A activación é a outra metade do fluxo. Un xerador que se desbloquea cun código do dispositivo, unha petición biométrica ou un contedor cifrado presenta unha proba de posesión máis algo distinto. Un que funciona sen cifrar e se desbloquea coa sesión do sistema operativo presenta só o ficheiro. A mesma aplicación pode ofrecer ambos os arranxos segundo como se fixo o rexistro, así que a decisión de despregamento está nese paso, non na páxina de márketing da aplicación.
Decida que demostra realmente o código
A linguaxe dos estándares é inusualmente clara aquí, e merece lectura directa. A guía de autenticadores do NIST enumera os xeradores OTP de software como autenticadores, distingue o OTP dun só factor do OTP multifactor cun factor de activación, e afirma que a autenticación OTP non resiste o phishing. Cada unha desas tres cláusulas cambia o que pode afirmar sobre o aviso.
Non resistir o phishing é a beira máis afiada. Un código escrito nun campo pódese escribir no campo doutra persoa, en tempo real, por alguén a quen convenceron de facelo. A xanela é curta, o que reduce o número de intentos útiles pero non pecha a técnica. Se o seu requisito inclúe resistir iso, o OTP é a primitiva equivocada sen importar onde se execute o xerador.
Un só factor fronte a multifactor é a segunda distinción. Un código que aparece sen paso de activación demostra a posesión dun ficheiro e nada máis, e o ficheiro é tan forte como a conta que o pode ler. Engada un factor de activación e a afirmación mellora, aínda que segue describindo a proba presentada no inicio de sesión, non o illamento da máquina que a produce.
Vexa ata onde pode chegar un portátil comprometido
Un atacante con execución de código na estación de traballo non se limita a ler o campo no que escribe. A sesión establecida tras un inicio de sesión correcto adoita ser un token ou unha cookie, e un token pódese usar desde outra máquina sen ningún código. Se esa é a capacidade contra a que se defende, engadir un segundo aviso no inicio de sesión cambia o número de pasos do ataque, non o resultado.
| 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 |
Lea a terceira columna como a honesta. Cada arranxo anterior deixa algo dentro da fronteira de confianza da estación de traballo, porque alí se usa a sesión. O que cambia é se o segredo de longa duración viaxa con esa fronteira ou queda fóra, e se a proba está ligada a unha orixe concreta para que unha páxina clonada non a poida reenviar.
Dous detalles menores pertencen á mesma imaxe. Un código segue sendo válido durante a súa xanela de aceptación, a miúdo trinta segundos máis unha tolerancia á desviación do reloxo, así que un valor capturado se pode reproducir dentro desa xanela salvo que o verificador rexeite a reutilización. E instalar un xerador novo non remata as sesións xa autenticadas, así que unha sesión antiga sobrevive ao cambio de credencial que debía conter o incidente.
Mova o xerador só onde a separación axuda
Pór o xerador de códigos nun teléfono é unha mellora real para un fallo concreto: un portátil roubado xa non leva ambas as probas. Non fai nada contra o secuestro de sesión no portátil, nada contra un usuario que escribe un código nunha páxina de phishing, e nada contra os códigos de recuperación que se imprimiron unha vez e se fotografaron nunha aplicación de notas.
Así que escriba o requisito antes de elixir a ferramenta. Se o obxectivo é unha proba adicional contra un contrasinal filtrado, dígao claramente, e a aplicación no mesmo dispositivo xa a entrega. Se o obxectivo é a resiliencia ao compromiso da estación de traballo VPN, nomee esa capacidade do atacante e elixa un arranxo avaliado para ela, co requisito de phishing enunciado á parte en lugar de suposto.
Logo trate a metade operativa, que decide se algo diso sobrevive ao contacto cun incidente. A perda dun dispositivo necesita unha ruta de substitución documentada, a rotación de credenciais necesita revogar as sesións activas, e o material de rexistro necesita a mesma protección que a semente, xa que unha copia de rexistro sen protexer entrega a un atacante os mesmos códigos futuros por unha ruta máis curta. Enumerar eses catro puntos é máis útil que discutir se os tokens no mesmo dispositivo son bos ou inútiles.