Chave de segurança vs aplicação de autenticação: o que o NIST diz de facto sobre phishing

A maioria das comparações entre estas duas opções resume-se a comodidade contra segurança, com a alegação vaga de que as chaves são "mais seguras". Existe uma resposta mais precisa, e está escrita numa norma.

A frase que resolve a questão do phishing

O NIST SP 800-63B, secção 5.2.5, é direto quanto a isto. Os autenticadores que envolvem a introdução manual de um output do autenticador, como os autenticadores out-of-band e OTP, não devem ser considerados resistentes à personificação do verificador, porque a introdução manual não liga o output do autenticador à sessão concreta que está a ser autenticada.

A mesma secção explica o ataque em vez de o deixar implícito: num ataque machine-in-the-middle, um verificador impostor poderia retransmitir o output do autenticador OTP para o verificador verdadeiro e autenticar-se com sucesso.

O mecanismo é todo este. O teu código de seis dígitos está correto. Está simplesmente correto em todo o lado, incluindo numa página que apenas se parece com a do teu banco.

Porque é que a ligação é a diferença real

A norma define a resistência à personificação do verificador como estabelecer um canal protegido e autenticado com o verificador e depois ligar de forma forte e irreversível um identificador de canal ao output do autenticador, por exemplo assinando os dois valores em conjunto com uma chave privada.

Lê isso à luz do que cada método faz fisicamente.

Uma aplicação de autenticação gera um número a partir de um segredo partilhado e de um relógio. Nunca chega a saber em que site estás. Tu és a camada de transporte, e podes ser desviado.

Uma chave de segurança assina um desafio em conjunto com a identidade da sessão. A FIDO Alliance descreve as passkeys como usando técnicas padrão de criptografia de chave pública para fornecer autenticação resistente a phishing. Não há número nenhum para leres em voz alta, e por isso nada que um atacante possa retransmitir.

Como é que o ataque se vê do teu lado

A abstração esconde o quão banal isto é, por isso vale a pena percorrê-lo.

Recebes uma mensagem acerca da tua conta. A ligação leva-te a uma página que aparece corretamente, porque o servidor do atacante está a ir buscar a página verdadeira e a reencaminhá-la. Introduzes a tua palavra-passe. O servidor do atacante submete-a de imediato no site verdadeiro. O site verdadeiro pede um segundo fator, por isso a página falsa também to pede.

Abres a tua aplicação e lês seis dígitos. O servidor do atacante introduz-nos no site verdadeiro dentro da mesma janela de trinta segundos. O site verdadeiro vê uma palavra-passe válida e um código válido, e emite uma sessão. O atacante fica agora com essa sessão.

Repara no que nunca aconteceu. Nada foi quebrado, nenhum segredo foi roubado do teu telemóvel, e a tua aplicação comportou-se exatamente como foi concebida. O código era genuíno. Foi apenas usado num sítio onde não tencionavas usá-lo, e nem tu nem a aplicação tinham forma de reparar nisso, porque o código não transporta qualquer informação sobre o seu destino.

Repete a mesma sequência com uma chave de segurança e ela para no segundo fator. A chave não produz um número para retransmitires. Assina uma resposta ligada ao site que está de facto a pedir, pelo que o servidor do atacante recebe algo que só funciona no seu próprio domínio, o que para ele não vale nada.

Onde uma chave também não ajuda

Ser preciso quanto aos limites conta tanto como quanto aos pontos fortes, porque uma chave não é um escudo para tudo.

Não protege uma sessão já emitida. Se malware na tua máquina roubar um cookie de sessão depois de teres iniciado sessão legitimamente, o passo de autenticação já ficou para trás e a chave deixou de estar envolvida.

Não protege o caminho de recuperação. Uma conta que pode ser reposta por email ou por um agente de apoio é apenas tão forte quanto esse caminho. É precisamente por isso que a conta de email é a primeira a proteger, e por isso que as perguntas de recuperação de conta continuam a ser um alvo fácil.

Não protege o que um dispositivo comprometido vê. Se o endpoint estiver totalmente comprometido, o atacante está dentro da sessão autenticada contigo.

Não cobre os serviços que não a suportam. É o limite prático para a maioria das pessoas, e a razão pela qual uma chave é um complemento a uma aplicação de autenticação e não um substituto dela.

A nuance que a maioria das comparações deixa cair

É aqui que muita escrita sobre segurança vai longe demais, por isso vale a pena dizê-lo com clareza.

A resistência à personificação do verificador só é exigida ao nível AAL3 no quadro do NIST. Em AAL1 e AAL2 não é obrigatória. Uma aplicação TOTP é, portanto, um segundo fator conforme para uma parte muito grande das contas comuns, e continua a ser uma melhoria importante face aos códigos por SMS ou a não ter segundo fator nenhum.

O enquadramento honesto não é, então, "as aplicações estão avariadas". É que as aplicações têm uma fraqueza específica, o phishing em tempo real, e que essa fraqueza é estrutural e não uma falha de uma aplicação em particular. Nenhuma atualização da tua aplicação de autenticação a vai corrigir, porque a lacuna está no próprio passo de introdução manual.

Escolher sem complicar

A decisão decorre do que um atacante ganha se uma dada conta cair.

Usa uma chave de segurança onde um comprometimento é irrecuperável. A tua conta de email primeiro, porque é o caminho de reposição de palavra-passe de tudo o resto. Depois o teu gestor de palavras-passe. Depois qualquer serviço financeiro que suporte chaves.

Mantém a aplicação para a abrangência. A maioria dos serviços continua a não suportar chaves de segurança. Uma aplicação de autenticação nessas contas é muito melhor do que nada, e não custa nada.

Não fiques com uma única chave sem alternativa. Regista uma segunda, ou guarda os códigos de recuperação impressos e arrumados offline. Perder a tua única chave é um bloqueio autoinfligido, e é uma falha mais comum do que ser vítima de phishing.

Se estás a decidir que chave comprar, comparamos os modelos atuais na nossa comparação de chaves de segurança de hardware.

Lado a lado

As duas últimas linhas são as que as pessoas subestimam. O risco real dominante com uma aplicação é ser levado a usá-la corretamente no momento errado. O risco real dominante com uma chave é perdê-la depois de teres registado apenas uma.

A versão curta

A questão do phishing não é matéria de opinião. O NIST afirma que os autenticadores OTP não podem ser considerados resistentes à personificação do verificador, e explica porquê: a introdução manual não liga o código à sessão. Uma chave de segurança assina a própria sessão, pelo que não há nada para retransmitir.

Mas o requisito aplica-se em AAL3, não em todo o lado. Uma aplicação de autenticação continua a ser um segundo fator legítimo para a maioria das contas. Põe chaves onde uma perda seria irrecuperável, mantém a aplicação para a cauda longa, e certifica-te de que tens uma forma de voltar a entrar.

As definições e os requisitos aqui descritos foram retirados da NIST Special Publication 800-63B, e a caracterização das passkeys do material da própria FIDO Alliance, ambos verificados à data de escrita. As normas são revistas; confirma no texto atual antes de te apoiares numa cláusula específica. As ligações comerciais têm o atributo rel="sponsored nofollow"; pode aplicar-se uma comissão de afiliação sem custo adicional para ti.