Sua senha de VPN é tão privada quanto o verificador dela

Percorra quatro perguntas sobre qualquer login de VPN: o que protege a senha em trânsito, qual componente a recebe, o que esse componente faz com ela e o que é armazenado depois. Cada resposta é um controle diferente, e uma resposta sólida a uma não diz nada sobre as outras. O erro é tratar a criptografia do túnel como se cobrisse as quatro. Ela cobre a primeira, e apenas a primeira.

Pergunte quem encerra a sessão, não se a sessão está criptografada.

Criptografada para quem, exatamente?

O TLS protege a senha entre o cliente e o que encerra a conexão. Se esse ponto final for o gateway VPN, o código de autenticação do gateway vê a senha em texto claro, valida-a e repassa adiante ela ou um valor derivado. Esse é o projeto pretendido, não um vazamento. Um observador de rede no caminho não aprende nada útil, e o componente que faz a verificação aprende tudo o que precisa.

A comunidade do OpenVPN documenta isso explicitamente: auth-user-pass-verify entrega as credenciais enviadas a um script ou plugin de verificação. É uma entrega intencional entre componentes, e pertence ao modelo de confiança como parte nomeada.

O verificador vê a senha

Depois que um componente recebe uma senha para verificá-la, seus controles de acesso, o registro e a qualidade do código decidem se o segredo permanece contido. Um script que grava a credencial em um log, ou um plugin que a armazena em cache, cria uma exposição muito maior do que o protocolo criou. O acesso depende da arquitetura e das funções, não do túnel, por isso o proprietário do serviço que controla o verificador entra na avaliação.

Métodos diferentes expõem material diferente. A autenticação por certificado prova uma chave privada sem enviá-la, e um fluxo de federação pode manter a senha no provedor de identidade enquanto emite uma asserção limitada à VPN. Esses projetos estreitam o círculo; nenhum deles elimina todas as partes confiáveis.

Hashes armazenados protegem um estágio diferente

A orientação do NIST separa a transmissão protegida do armazenamento resistente do verificador. O sal e um esquema de hash com custo tratam da ameaça do verificador armazenado, que é o que acontece depois do fato se um banco de dados vazar. Eles não fazem nada por um componente em tempo de execução que precisa receber a entrada para compará-la. Ler a orientação como se prometesse sigilo em tempo de execução é um erro de categoria.

Um armazenamento de senhas bem protegido por hash e um script de verificação exposto podem, portanto, coexistir em um único produto sem contradição.

Escolher um método que estreite o círculo

Se o requisito é que o gateway nunca receba uma senha reutilizável, escolha um método que realmente garanta isso; trocar a cifra de dados não cria essa propriedade. Verificar o certificado do servidor VPN informa a qual par você chegou; não diz nada sobre como esse par lida com as credenciais depois. Mantenha a verificação do servidor, use credenciais distintas por serviço e siga o fluxo de identidade suportado pela organização.

Registre a parte que recebe a senha, a parte que a valida e a forma na qual ela é mantida. Essas três respostas pertencem ao lado do perfil de conexão, porque sobrevivem a qualquer túnel específico.

A pergunta útil não é se a senha está criptografada, mas de quem ela está escondida, qual componente a recebe e que forma sobrevive depois.