Primeiro o método EAP: que hash de palavra-passe uma VPN pode usar
Uma VPN verifica o segredo, não o hash web. Leia o método e depois confira o que o armazém guarda antes de prometer que as mesmas palavras-passe continuarão a funcionar.
Muitas equipas têm um início de sessão web que funciona e uma VPN que recusa todas as palavras-passe da mesma tabela. A aplicação web compara um hash que calculou ela própria, enquanto o túnel pede ao cliente que prove a posse de um segredo de uma forma que o servidor tem de conseguir verificar. São requisitos diferentes sobre o material armazenado. É na diferença entre ambos que a maioria destes projetos encrava.
Primeiro o método, depois o esquema
Anote que prova exige o método escolhido antes de olhar para qualquer esquema. Um método de desafio-resposta precisa de material a partir do qual o servidor possa calcular a resposta esperada, o que na prática significa a palavra-passe ou uma forma derivada compatível. Um método que transporta a palavra-passe dentro de um túnel protegido precisa da própria palavra-passe no verificador. Leia a documentação do método pelo requisito do verificador e não pela configuração do cliente, porque os requisitos do cliente são normalmente a parte fácil.
Um hash com sal produzido por uma framework web moderna não fornece nenhuma das duas coisas. Verifica uma comparação concreta e não pode ser revertido para o segredo de onde veio.
O desafio-resposta não pode usar um hash com sal
O MSCHAPv2 é uma troca de desafio-resposta, pelo que o servidor nunca recebe a palavra-passe e não pode comparar uma cadeia armazenada. Tem de derivar a resposta esperada a partir do material que já possui, e é por isso que as formas armazenadas compatíveis são tão estreitas. Um valor bcrypt ou Argon2 com um sal por utilizador é de sentido único de uma forma que exclui a troca por completo. A tabela abaixo parte da forma de armazenamento e não do nome do método, porque é a forma de armazenamento que decide a resposta.
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
A documentação do plug-in SQL para o strongSwan define um esquema próprio para configuração e credenciais, e o projeto continua a marcar esse plug-in como experimental. Nada nela se adapta à tabela de utilizadores de uma aplicação nem adivinha que esquema de hash produziu um valor armazenado. As opções realistas são, portanto, a migração para um armazém que o gateway possa usar, ou um serviço de autenticação à frente do armazém existente que consiga realizar a troca. Qualquer outra coisa é um conector com uma suposição escondida lá dentro.
O RADIUS move o trabalho, não o requisito
Delegar o EAP num servidor RADIUS muda o local onde a verificação acontece e normalmente melhora o rasto de auditoria. Não recupera uma palavra-passe a partir de um hash de sentido único, pelo que o serviço de autenticação continua a precisar de material compatível com o método que termina. As equipas descobrem isto depois de construírem o caminho RADIUS e de encontrarem o mesmo muro do outro lado.
Onde o servidor RADIUS consegue ler um diretório com uma credencial compatível, o desenho funciona e o gateway VPN mantém-se simples. Onde não consegue, a resposta honesta é uma alteração no registo e não outro conector. O aprovisionamento e a revogação pertencem a quem é dono da identidade, por isso uma tabela copiada sem um processo de sincronização suportado é um segundo ciclo de vida de credenciais e não um início de sessão único. Desvia-se na primeira vez que alguém repõe uma palavra-passe num só local, e o desvio é silencioso até uma conta que existe nos dois sistemas se comportar de forma diferente em cada um.
Limite a conta que lê o diretório a essa leitura e mantenha-a separada da conta que o gateway usa para a sua própria configuração. Uma conta administrativa partilhada transforma um desenho só de leitura num raio de impacto muito maior.
Onde a conta deve viver
Resolvida a questão do material, restam duas arquiteturas. O gateway pode ter um pequeno armazém de credenciais que só ele lê, ou delegar num serviço de autenticação que se coloca à frente do diretório da empresa.
A primeira é mais fácil de raciocinar e pior para o utilizador, que acaba com uma segunda palavra-passe para manter. A segunda conserva uma só identidade e acrescenta uma dependência de um serviço que agora tem de estar ativo antes de alguém se poder ligar. Nenhuma está errada, mas a escolha deve ficar registada ao lado da configuração do gateway, porque de contrário o próximo engenheiro assumirá que foi escolhida a outra. Escolha o que escolher, os dois comandos abaixo são os que mostram o estado atual antes de o alterar.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsA autenticação da conta também não resolve a autorização. A pertença a grupos, o estado do dispositivo e a permissão de rede continuam a precisar de um mapeamento explícito depois de o utilizador ter provado a identidade exigida. Uma ligação que se autentica na perfeição e não autoriza nada é um resultado de política, não um defeito do método.