Duas solicitações de senha não são MFA: o que um login VPN verifica
Um segundo campo de senha, uma cifra forte e um certificado de dispositivo provam algo cada um. Apenas fatores distintos vinculados a uma mesma conta contam como multifator.
A página de login pede uma senha e depois um segundo segredo, e a implantação logo é descrita como multifator. Às vezes é. Muitas vezes é um único fator coletado duas vezes, porque ambos os valores são conhecimento que a mesma pessoa digitou da mesma memória ou da mesma nota. Uma cifra de túnel forte não muda isso, e a palavra «seguro» no nome do produto também não.
Separar a alegação do mecanismo exige uma única pergunta: o que cada etapa prova, e a quem?
Um fator é uma prova, não um campo
A autenticação multifator significa que mais de um tipo distinto de prova é verificado para a mesma conta: algo que o usuário sabe, algo que possui, algo que é. Dois campos que coletam ambos uma sequência memorizada são um único tipo de prova pedido duas vezes. Isso pode ser um controle útil, já que dois segredos independentes são mais difíceis de adivinhar do que um, mas não é o que o termo descreve e não deve ser contado como tal numa avaliação de risco.
O lado da verificação importa tanto quanto o lado da coleta. Um código gerado num dispositivo só prova o controle desse dispositivo se o servidor o verifica contra um segredo vinculado a esta conta e rejeita repetições. Um código compartilhado que funciona para todos, um código sem limite de taxa ou uma solicitação aprovada num dispositivo que nunca mostra o que está sendo aprovado são todos mais fracos do que o rótulo sugere.
Então, quando alguém perguntar se a VPN tem MFA, pergunte o que a segunda etapa prova e como o servidor a vincula. Se a resposta for «uma segunda senha do mesmo diretório», você tem um fator e uma conversa sobre políticas, não um segundo fator.
O caso do certificado precisa ser lido, não presumido
Um certificado de cliente mais uma senha parece dois fatores, e pode ser: o certificado fica num armazenamento ou num token, e a senha é memorizada. Também pode ser um só, se o arquivo do certificado estiver sem proteção no mesmo diretório de perfil da senha salva, ou se o certificado foi emitido para um dispositivo que várias pessoas compartilham sem responsabilidade individual.
A questão a resolver é quem ou o que o certificado identifica. Um certificado de dispositivo prova que há uma máquina gerenciada presente. Um certificado de usuário prova uma identidade. Se a implantação emite um certificado por notebook e depois trata sua presença como prova da pessoa, o segundo fator se tornou silenciosamente uma propriedade do hardware que qualquer um que segure o notebook herda.
Nada disso torna os certificados uma má ideia. Torna a distinção entre garantia do dispositivo e garantia do usuário digna de ser registrada, porque as duas respondem a perguntas diferentes e uma planilha de conformidade que as conta como uma vai superestimar o que está protegido.
A confiança no gateway e a confiança no usuário são problemas separados
Um segundo fator não torna seguro digitar credenciais num endpoint que você não verificou. O cliente precisa reconhecer o gateway pretendido, e é para isso que servem o certificado do servidor e a configuração de confiança do cliente. O phishing funciona movendo o login para um servidor que o atacante controla, e um código de uso único correto digitado ali é simplesmente repassado ao serviço real em tempo real.
É por isso que a escolha do método muda o resultado mais do que a redação da solicitação. Códigos digitados por uma pessoa podem ser repassados por qualquer um que consiga apresentar uma página convincente, enquanto métodos criptográficos que vinculam a autenticação à origem e à sessão específicas resistem a esse repasse por projeto. Qual dos dois você tem é uma propriedade do método, não do número de etapas no diálogo.
Siga o fluxo de inscrição e de cliente suportado pelo fornecedor em vez de parafusar uma solicitação extra num campo de senha. Um segundo passo caseiro geralmente fica em algum lugar entre os dois, adicionando atrito sem a vinculação que dá sentido ao fator.
A recuperação é a segunda porta de entrada
Todo login forte tem um caminho de volta quando o autenticador se perde, e esse caminho é onde o projeto costuma ser mais fraco. Se um agente de suporte pode redefinir o segundo fator após uma ligação para um número cadastrado, a rota mais barata do atacante é o service desk, não a página de login.
Pergunte como funciona a substituição, quem a aprova e quais provas exigem. Depois verifique se o material de recuperação, como códigos de backup, é guardado separadamente da credencial principal, para que um único comprometimento não entregue as duas. A orientação sobre identidade digital do NIST trata a vinculação do verificador e o ciclo de vida do autenticador como parte do requisito, não como uma reflexão operacional.
O que escrever na avaliação
Descreva os fatores por tipo, nomeie o que cada um prova e declare como ele está vinculado à conta. Anote se o método resiste ao repasse e descreva o caminho de recuperação com o mesmo cuidado do login.
Depois diga claramente se a implantação é multifator segundo essa definição. «Duas senhas e um certificado de máquina» é uma frase honesta, e diz a um leitor muito mais do que uma caixa de seleção que marca sim.