Su contraseña de VPN es tan privada como su verificador

Repase cuatro preguntas sobre cualquier inicio de sesión VPN: qué protege la contraseña en tránsito, qué componente la recibe, qué hace ese componente con ella y qué se almacena después. Cada respuesta es un control distinto, y una respuesta sólida a una no dice nada de las demás. El error es tratar el cifrado del túnel como si cubriera las cuatro. Cubre la primera, y solo la primera.

Pregunte quién termina la sesión, no si la sesión está cifrada.

¿Cifrada para quién, exactamente?

TLS protege la contraseña entre el cliente y lo que termina la conexión. Si ese punto final es la puerta de enlace VPN, el código de autenticación de la puerta de enlace ve la contraseña en texto claro, la valida y la transmite, o transmite un valor derivado. Ese es el diseño previsto, no una fuga. Un observador de red en la ruta no aprende nada útil, y el componente que realiza la verificación aprende todo lo que necesita.

La comunidad de OpenVPN lo documenta explícitamente: auth-user-pass-verify entrega las credenciales enviadas a un script o complemento de verificación. Es una entrega intencionada entre componentes, y pertenece al modelo de confianza como parte nombrada.

El verificador ve la contraseña

Una vez que un componente recibe una contraseña para verificarla, sus controles de acceso, su registro y la calidad de su código deciden si el secreto permanece contenido. Un script que escribe la credencial en un registro, o un complemento que la almacena en caché, crea una exposición mucho mayor que la del protocolo. El acceso depende de la arquitectura y los roles, no del túnel, por eso el propietario del servicio que controla el verificador pertenece a la evaluación.

Distintos métodos exponen distinto material. La autenticación por certificado demuestra una clave privada sin enviarla, y un flujo de federación puede mantener la contraseña en el proveedor de identidad mientras emite una aserción limitada a la VPN. Esos diseños estrechan el círculo; ninguno elimina todas las partes de confianza.

Los hashes almacenados protegen una etapa distinta

La guía de NIST separa la transmisión protegida del almacenamiento resistente del verificador. La sal y un esquema de hash con coste abordan la amenaza del verificador almacenado, que es lo que ocurre a posteriori si una base de datos se filtra. No hacen nada por un componente en tiempo de ejecución que debe recibir la entrada para compararla. Leer la guía como si prometiera secreto en tiempo de ejecución es un error de categoría.

Así pues, un almacén de contraseñas bien hasheado y un script de verificación expuesto pueden coexistir en un producto sin contradicción.

Elegir un método que estreche el círculo

Si el requisito es que la puerta de enlace nunca reciba una contraseña reutilizable, elija un método que realmente lo garantice; cambiar un cifrado de datos no crea esa propiedad. Verificar el certificado del servidor VPN le dice a qué par llegó; no dice nada sobre cómo ese par maneja las credenciales después. Mantenga la verificación del servidor, use credenciales distintas por servicio y siga el flujo de identidad que admite la organización.

Registre la parte que recibe la contraseña, la parte que la valida y la forma en que se conserva. Esas tres respuestas pertenecen junto al perfil de conexión, porque sobreviven a cualquier túnel concreto.

La pregunta útil no es si la contraseña está cifrada, sino de quién se oculta, qué componente la recibe y qué forma sobrevive después.