¿Es realmente un segundo factor el TOTP en el mismo portátil?

Inicie sesión en un cliente VPN que pide una contraseña y luego un código de seis dígitos, y dos avisos parecen dos barreras independientes. Contados por tipo de factor, lo son: la contraseña es algo que sabe, el código es algo que posee. Contados por lo que expone un solo portátil comprometido, pueden colapsar en una sola frontera, porque lo que posee es un archivo en la máquina en la que escribe. La brecha entre esos dos recuentos es el tema de este recorrido.

Siga un inicio de sesión desde el campo de contraseña hasta la casilla del código

Observe la secuencia, no las etiquetas. El cliente envía la contraseña, el servidor responde que hace falta una segunda prueba y el cliente abre un campo para seis u ocho dígitos. Detrás de ese campo hay una aplicación generadora que guarda un secreto compartido y un reloj. Calcula un valor a partir del secreto y del paso de tiempo actual, y el servidor recalcula el mismo valor a partir de su copia del secreto.

Ambos lados guardan el mismo material de clave. Esa simetría es la parte que la gente pasa por alto cuando describe el código como un secreto: el proveedor también puede generar sus códigos, y por eso la semilla vale más que cualquier salida individual. Un código que se filtra es un valor de un solo uso; la semilla que lo produjo es una credencial permanente que sigue produciendo valores válidos hasta que se reemplaza.

La activación es la otra mitad del flujo. Un generador que se desbloquea con un código del dispositivo, una petición biométrica o un contenedor cifrado presenta una prueba de posesión más algo distinto. Uno que funciona sin cifrar y se desbloquea con la sesión del sistema operativo presenta solo el archivo. La misma aplicación puede ofrecer ambos arreglos según cómo se hizo el registro, así que la decisión de despliegue está en ese paso, no en la página de marketing de la aplicación.

Decida qué demuestra realmente el código

El lenguaje de los estándares es inusualmente claro aquí, y merece lectura directa. La guía de autenticadores del NIST enumera los generadores OTP de software como autenticadores, distingue el OTP de un solo factor del OTP multifactor con un factor de activación, y afirma que la autenticación OTP no resiste el phishing. Cada una de esas tres cláusulas cambia lo que puede afirmar sobre el aviso.

No resistir el phishing es el borde más afilado. Un código escrito en un campo se puede escribir en el campo de otra persona, en tiempo real, por alguien a quien convencieron de hacerlo. La ventana es corta, lo que reduce el número de intentos útiles pero no cierra la técnica. Si su requisito incluye resistir eso, el OTP es la primitiva equivocada sin importar dónde se ejecute el generador.

Un solo factor frente a multifactor es la segunda distinción. Un código que aparece sin paso de activación demuestra la posesión de un archivo y nada más, y el archivo es tan fuerte como la cuenta que puede leerlo. Añada un factor de activación y la afirmación mejora, aunque todavía describe la prueba presentada al iniciar sesión, no el aislamiento de la máquina que lo produce.

Vea a qué puede llegar un portátil comprometido

Un atacante con ejecución de código en la estación de trabajo no se limita a leer el campo en el que escribe. La sesión establecida tras un inicio de sesión correcto suele ser un token o una cookie, y un token se puede usar desde otra máquina sin ningún código. Si esa es la capacidad contra la que se defiende, añadir un segundo aviso al iniciar sesión cambia el número de pasos del ataque, no el resultado.

Lea la tercera columna como la honesta. Cada arreglo anterior deja algo dentro de la frontera de confianza de la estación de trabajo, porque allí se usa la sesión. Lo que cambia es si el secreto de larga duración viaja con esa frontera o se queda fuera, y si la prueba está ligada a un origen concreto para que una página clonada no pueda reenviarla.

Dos detalles menores pertenecen a la misma imagen. Un código sigue siendo válido durante su ventana de aceptación, a menudo treinta segundos más una tolerancia a la desviación del reloj, así que un valor capturado se puede reproducir dentro de esa ventana salvo que el verificador rechace la reutilización. E instalar un generador nuevo no termina las sesiones ya autenticadas, así que una sesión antigua sobrevive al cambio de credencial que debía contener el incidente.

Mueva el generador solo donde la separación ayuda

Poner el generador de códigos en un teléfono es una mejora real para un fallo concreto: un portátil robado ya no lleva ambas pruebas. No hace nada contra el secuestro de sesión en el portátil, nada contra un usuario que escribe un código en una página de phishing, y nada contra los códigos de recuperación que se imprimieron una vez y se fotografiaron en una aplicación de notas.

Así que escriba el requisito antes de elegir la herramienta. Si el objetivo es una prueba adicional contra una contraseña filtrada, dígalo sin rodeos, y la aplicación en el mismo dispositivo ya la entrega. Si el objetivo es la resiliencia al compromiso de la estación de trabajo VPN, nombre esa capacidad del atacante y elija un arreglo evaluado para ella, con el requisito de phishing enunciado aparte en lugar de supuesto.

Luego trate la mitad operativa, que decide si algo de eso sobrevive al contacto con un incidente. La pérdida de un dispositivo necesita una ruta de sustitución documentada, la rotación de credenciales necesita revocar las sesiones activas, y el material de registro necesita la misma protección que la semilla, ya que una copia de registro sin proteger entrega a un atacante los mismos códigos futuros por una ruta más corta. Enumerar esos cuatro puntos es más útil que discutir si los tokens en el mismo dispositivo son buenos o inútiles.