Dos solicitudes de contraseña no son MFA: qué verifica un inicio de sesión VPN

La página de inicio de sesión pide una contraseña y luego un segundo secreto, y enseguida se describe el despliegue como multifactor. A veces lo es. A menudo es un solo factor recogido dos veces, porque ambos valores son conocimientos que la misma persona escribió de la misma memoria o de la misma nota. Un cifrado de túnel fuerte no cambia eso, y la palabra «seguro» en el nombre del producto tampoco.

Separar la afirmación del mecanismo requiere una sola pregunta: ¿qué demuestra cada paso, y a quién?

Un factor es una prueba, no un campo

La autenticación multifactor significa que se verifica más de un tipo distinto de prueba para la misma cuenta: algo que el usuario sabe, algo que posee, algo que es. Dos campos que recogen ambos una cadena recordada son un solo tipo de prueba pedido dos veces. Puede ser un control útil, ya que dos secretos independientes son más difíciles de adivinar que uno, pero no es lo que describe el término y no debería contarse como tal en una evaluación de riesgos.

El lado de la verificación importa tanto como el lado de la recogida. Un código generado en un dispositivo demuestra el control de ese dispositivo solo si el servidor lo comprueba contra un secreto vinculado a esta cuenta y rechaza las repeticiones. Un código compartido que sirve para todos, un código sin límite de intentos o una solicitud aprobada en un dispositivo que nunca muestra qué se está aprobando son más débiles de lo que sugiere la etiqueta.

Así que cuando alguien pregunte si la VPN tiene MFA, pregunte qué demuestra el segundo paso y cómo lo vincula el servidor. Si la respuesta es «una segunda contraseña del mismo directorio», tiene un factor y una conversación sobre políticas, no un segundo factor.

El caso del certificado se lee, no se supone

Un certificado de cliente más una contraseña parece dos factores, y puede serlo: el certificado se guarda en un almacén o en un token, y la contraseña se recuerda. También puede ser uno, si el archivo del certificado está sin protección en el mismo directorio de perfil que la contraseña guardada, o si el certificado se emitió para un dispositivo que varias personas comparten sin responsabilidad individual.

La cuestión a resolver es a quién o a qué identifica el certificado. Un certificado de dispositivo demuestra que hay una máquina gestionada presente. Un certificado de usuario demuestra una identidad. Si el despliegue emite un certificado por portátil y luego trata su presencia como prueba de la persona, el segundo factor se ha convertido en silencio en una propiedad del hardware que hereda cualquiera que tenga el portátil.

Nada de eso hace que los certificados sean una mala idea. Hace que la distinción entre garantía del dispositivo y garantía del usuario merezca escribirse, porque las dos responden a preguntas distintas y una hoja de cálculo de cumplimiento que las cuenta como una exagerará lo que está protegido.

La confianza en la puerta de enlace y la confianza en el usuario son problemas separados

Un segundo factor no hace seguro escribir credenciales en un punto final que no ha verificado. El cliente tiene que reconocer la puerta de enlace prevista, y para eso están el certificado del servidor y la configuración de confianza del cliente. El phishing funciona trasladando el inicio de sesión a un servidor que controla el atacante, y un código de un solo uso correcto introducido allí se reenvía sin más al servicio real en tiempo real.

Por eso la elección del método cambia el resultado más que la redacción de la solicitud. Los códigos escritos por una persona pueden ser reenviados por cualquiera que pueda mostrar una página convincente, mientras que los métodos criptográficos que vinculan la autenticación al origen y a la sesión concretos resisten ese reenvío por diseño. Cuál de los dos tiene usted es una propiedad del método, no del número de pasos del diálogo.

Siga el flujo de inscripción y de cliente que admite el proveedor en lugar de atornillar una solicitud adicional a un campo de contraseña. Un segundo paso casero suele quedar en algún punto intermedio, añadiendo fricción sin la vinculación que da sentido al factor.

La recuperación es la segunda puerta de entrada

Todo inicio de sesión fuerte tiene un camino de vuelta cuando se pierde el autenticador, y ese camino es donde el diseño suele ser más débil. Si un agente de soporte puede restablecer el segundo factor tras una llamada a un número registrado, la ruta más barata para el atacante es el servicio de ayuda, no la página de inicio de sesión.

Pregunte cómo funciona la sustitución, quién la aprueba y qué pruebas exigen. Luego compruebe que el material de recuperación, como los códigos de respaldo, se guarda por separado de la credencial principal, de modo que una sola brecha no entregue ambas. La guía sobre identidad digital del NIST trata la vinculación del verificador y el ciclo de vida del autenticador como parte del requisito, no como una reflexión operativa.

Qué escribir en la evaluación

Describa los factores por tipo, nombre qué demuestra cada uno y exponga cómo está vinculado a la cuenta. Anote si el método resiste el reenvío y describa el camino de recuperación con el mismo cuidado que el inicio de sesión.

Luego diga con claridad si el despliegue es multifactor según esa definición. «Dos contraseñas y un certificado de máquina» es una frase honesta, y le dice a un lector mucho más que una casilla que marque sí.