O TOTP no mesmo notebook é realmente um segundo fator?
Um gerador de códigos no notebook da VPN é um fator de posse que fica dentro da mesma fronteira de comprometimento. Rastreie primeiro a semente e a sessão.
Entre em um cliente VPN que pede uma senha e depois um código de seis dígitos, e dois pedidos parecem duas barreiras independentes. Contados por tipo de fator, eles são: a senha é algo que você sabe, o código é algo que você possui. Contados pelo que um único notebook comprometido expõe, podem colapsar em uma só fronteira, porque o que você possui é um arquivo na máquina em que digita. A diferença entre essas duas contagens é o tema deste percurso.
Rastreie um login do campo de senha até a caixa do código
Observe a sequência, não os rótulos. O cliente envia a senha, o servidor responde que uma segunda prova é necessária, e o cliente abre um campo para seis ou oito dígitos. Atrás desse campo há um aplicativo gerador que guarda um segredo compartilhado e um relógio. Ele calcula um valor a partir do segredo e do passo de tempo atual, e o servidor recalcula o mesmo valor a partir da cópia dele do segredo.
Os dois lados guardam o mesmo material de chave. Essa simetria é a parte que as pessoas perdem quando descrevem o código como um segredo: o provedor também pode gerar seus códigos, e é por isso que a semente vale mais do que qualquer saída isolada. Um código que vaza é um valor de uso único; a semente que o produziu é uma credencial permanente que continua produzindo valores válidos até ser substituída.
A ativação é a outra metade do fluxo. Um gerador que desbloqueia com um código do dispositivo, um pedido biométrico ou um contêiner criptografado apresenta uma prova de posse mais outra coisa. Um que roda sem criptografia e desbloqueia com a sessão do sistema operacional apresenta apenas o arquivo. O mesmo aplicativo pode oferecer os dois arranjos conforme a forma como o registro foi feito, então a decisão de implantação está nesse passo, não na página de marketing do aplicativo.
Decida o que o código realmente prova
A linguagem dos padrões é incomumente clara aqui, e vale a leitura direta. O guia de autenticadores do NIST lista geradores de OTP baseados em software como autenticadores, distingue o OTP de fator único do OTP multifator com um fator de ativação, e afirma que a autenticação por OTP não é resistente a phishing. Cada uma dessas três cláusulas muda o que você pode alegar sobre o pedido.
Não resistir a phishing é a aresta mais afiada. Um código digitado em um campo pode ser digitado no campo de outra pessoa, em tempo real, por alguém que foi convencido a isso. A janela é curta, o que reduz o número de tentativas úteis mas não fecha a técnica. Se o seu requisito inclui resistir a isso, o OTP é a primitiva errada, não importa onde o gerador roda.
Fator único contra multifator é a segunda distinção. Um código que aparece sem etapa de ativação prova a posse de um arquivo e nada mais, e o arquivo é tão forte quanto a conta que pode lê-lo. Adicione um fator de ativação e a alegação melhora, embora ainda descreva a prova apresentada no login, não o isolamento da máquina que a produz.
Veja até onde um notebook comprometido pode chegar
Um atacante com execução de código na estação de trabalho não se limita a ler o campo em que você digita. A sessão estabelecida após um login bem-sucedido costuma ser um token ou um cookie, e um token pode ser usado de outra máquina sem nenhum código. Se essa é a capacidade contra a qual você se defende, acrescentar um segundo pedido no login muda o número de passos do ataque, não o resultado.
| Arrangement | What it adds at login | What it leaves inside the laptop boundary |
|---|---|---|
| Password plus TOTP app on the same machine | A possession proof the password alone does not supply | The seed, the unlock step and the authenticated session |
| TOTP app on a separate phone | Seed storage outside the workstation | Session cookies, the typed password and any prompt that can be proxied |
| Hardware key with a signed challenge | A per-login signature bound to the origin | Whatever the browser and the workstation are already trusted to do |
Leia a terceira coluna como a honesta. Todo arranjo acima deixa algo dentro da fronteira de confiança da estação de trabalho, porque é ali que a sessão é usada. O que muda é se o segredo de longa duração viaja com essa fronteira ou fica fora dela, e se a prova está vinculada a uma origem específica para que uma página imitada não possa repassá-la.
Dois detalhes menores pertencem à mesma imagem. Um código permanece válido durante a sua janela de aceitação, muitas vezes trinta segundos mais uma tolerância ao desvio do relógio, então um valor capturado pode ser reproduzido dentro dessa janela a menos que o verificador recuse a reutilização. E instalar um novo gerador não encerra sessões que já foram autenticadas, então uma sessão antiga sobrevive à troca de credencial que deveria conter o incidente.
Mova o gerador só para onde a separação ajuda
Colocar o gerador de códigos no celular é uma melhoria real para uma falha específica: um notebook roubado já não carrega as duas provas. Não faz nada contra o sequestro de sessão no notebook, nada por um usuário que digita um código em uma página de phishing, e nada pelos códigos de recuperação que foram impressos uma vez e fotografados em um aplicativo de notas.
Então escreva o requisito antes de escolher a ferramenta. Se o objetivo é uma prova extra contra uma senha vazada, diga isso claramente, e o aplicativo no mesmo dispositivo já a entrega. Se o objetivo é a resiliência ao comprometimento da estação de trabalho da VPN, nomeie essa capacidade do atacante e escolha um arranjo avaliado para ela, com o requisito de phishing declarado em separado em vez de presumido.
Depois trate a metade operacional, que decide se algo disso sobrevive ao contato com um incidente. A perda de um dispositivo exige um caminho de substituição documentado, a rotação de credenciais exige revogar as sessões ativas, e o material de registro exige a mesma proteção da semente, já que uma cópia de registro desprotegida entrega ao atacante os mesmos códigos futuros por uma rota mais curta. Enumerar esses quatro pontos é mais útil do que discutir se os tokens no mesmo dispositivo são bons ou inúteis.