O seu contrasinal VPN é tan privado como o seu verificador

Repase catro preguntas sobre calquera inicio de sesión VPN: que protexe o contrasinal en tránsito, que compoñente o recibe, que fai ese compoñente con el e que se almacena despois. Cada resposta é un control distinto, e unha resposta sólida a unha non di nada das demais. O erro é tratar o cifrado do túnel como se cubrise as catro. Cobre a primeira, e só a primeira.

Pregunte quen remata a sesión, non se a sesión está cifrada.

¿Cifrada para quen, exactamente?

TLS protexe o contrasinal entre o cliente e o que remata a conexión. Se ese punto final é a pasarela VPN, o código de autenticación da pasarela ve o contrasinal en texto claro, valídao e transmite despois el ou un valor derivado. Ese é o deseño previsto, non unha fuga. Un observador de rede na ruta non aprende nada útil, e o compoñente que realiza a verificación aprende todo o que necesita.

A comunidade de OpenVPN documéntao explicitamente: auth-user-pass-verify entrega as credenciais enviadas a un script ou complemento de verificación. É unha entrega intencionada entre compoñentes, e pertence ao modelo de confianza como parte nomeada.

O verificador ve o contrasinal

Unha vez que un compoñente recibe un contrasinal para verificalo, os seus controis de acceso, o rexistro e a calidade do código deciden se o segredo permanece contido. Un script que escribe a credencial nun rexistro, ou un complemento que a almacena na caché, crea unha exposición moito maior que a do protocolo. O acceso depende da arquitectura e dos roles, non do túnel, por iso o propietario do servizo que controla o verificador pertence á avaliación.

Métodos distintos expoñen material distinto. A autenticación por certificado demostra unha clave privada sen enviarla, e un fluxo de federación pode manter o contrasinal no provedor de identidade mentres emite unha aserción limitada á VPN. Eses deseños estreitan o círculo; ningún deles elimina todas as partes de confianza.

Os hashes almacenados protexen unha etapa distinta

A guía de NIST separa a transmisión protexida do almacenamento resistente do verificador. O sal e un esquema de hash con custo abordan a ameaza do verificador almacenado, que é o que ocorre a posteriori se unha base de datos se filtra. Non fan nada por un compoñente en tempo de execución que debe recibir a entrada para comparala. Ler a guía como se prometese segredo en tempo de execución é un erro de categoría.

Así pois, un almacén de contrasinais ben hasheado e un script de verificación exposto poden coexistir nun produto sen contradición.

Escoller un método que estreite o círculo

Se o requisito é que a pasarela nunca reciba un contrasinal reutilizable, escolla un método que realmente o garanta; cambiar un cifrado de datos non crea esa propiedade. Verificar o certificado do servidor VPN dille a que par chegou; non di nada sobre como ese par manexa as credenciais despois. Manteña a verificación do servidor, use credenciais distintas por servizo e siga o fluxo de identidade que admite a organización.

Rexiste a parte que recibe o contrasinal, a parte que o valida e a forma en que se conserva. Esas tres respostas pertencen xunto ao perfil de conexión, porque sobreviven a calquera túnel concreto.

A pregunta útil non é se o contrasinal está cifrado, senón de quen se oculta, que compoñente o recibe e que forma sobrevive despois.