Como funcionam os autenticadores?

A maioria desses aplicativos segue o mesmo algoritmo, OATH TOTP (conforme definido no IETF RFC 6238).

Funciona totalmente offline – o código QR que você escaneia contém uma chave secreta da qual derivam os códigos de 6 dígitos, em combinação com o carimbo de data/hora atual (arredondado para o meio minuto mais próximo). O mesmo código pode, portanto, ser importado para vários aplicativos e eles gerarão o mesmo código de forma totalmente independente, desde que os relógios correspondam.

(Há exceções; por exemplo, RSA SecurID costumava ser comum no passado, OATH HOTP é uma possibilidade rara – baseada em contador em vez de baseada em tempo – e alguns aplicativos usam seus próprios algoritmos por razões históricas ou não, mas OATH TOTP é o único geralmente aceito na web.)

O núcleo do algoritmo é apenas HMAC_SHA1(secret_key, timestamp). A maioria dos sites tem a opção de mostrar a chave secreta em formato de texto em vez de um código QR, e então você pode usar oathtool ou hotpie para experimentá-la. (Certifique-se de não deixar a chave secreta por perto.)

$ oathtool --base32 --totp ABCDEFG
534266

O código QR contém otpauth://totp/USER?secret=ABC&issuer=SITE, ou seja, a mesma chave secreta mais o rótulo de entrada (que é apenas para fins de exibição).

$ qrencode "otpauth://totp/User?secret=ABCDEFG&issuer=Demo"

A versão resumida é: eles geram o código da mesma maneira. Acredito que TOTP é o 'padrão' aqui. Uma das coisas boas dos sistemas modernos e sempre on-line é que você tem uma sincronização de tempo confiável - usando isso e uma chave privada (que está incluída no código QR que você escaneia) e o mesmo algoritmo, você pode gerar um previsível. chave de tempo sem um ponto central de autenticação.

Isso também significa que, em teoria (e prática), você pode exportar suas chaves para outro dispositivo/cliente TOTP e, desde que seus relógios sejam razoavelmente precisos, ele deverá funcionar.

Se não me falha a memória, eles usam o OTP que você fornece na primeira vez para confirmar que é a hora e a chave 'corretas', mas não tenho certeza disso.

O conceito central por trás de todos os sistemas de autenticação de dois fatores devidamente protegidos envolve o usuário provar sua identidade usando algum mecanismo previamente acordado que não pode ser razoavelmente replicado.

O mecanismo específico usado pela maioria dos aplicativos 'autenticadores' é conhecido como TOTP (Time-based One Time Password). Esta é uma variante modificada de um mecanismo mais antigo conhecido como HOTP (HMAC One Time Password). A configuração de qualquer um dos mecanismos funciona da seguinte maneira.

1. Quando o usuário solicita que um determinado serviço habilite 2FA, esse serviço gera um segredo a ser usado para fins de autenticação. Os detalhes exatos desta geração não importam muito aqui, e você pode pensar funcionalmente no segredo como um número aleatório entre 0 e algum número arbitrariamente grande.
2. O serviço então compartilha esse número com o usuário, normalmente por meio de um código QR que codifica uma URL especial usando o otpauth://esquema. Os detalhes disso também não são particularmente importantes para a discussão, apenas saiba que ele codifica o segredo (e as informações sobre o próprio site) de forma que o dispositivo autenticador possa lê-lo.
3. Depois que o autenticador lê o segredo, ele o armazena (espero) de forma segura, juntamente com informações sobre o provedor da conta (e normalmente alguns pequenos comentários para lembrar ao usuário qual conta é, caso ele tenha mais de uma com esse provedor).
4. O servidor então (espero) armazena o segredo com segurança e o associa à conta do usuário. Ele pode solicitar um ou mais códigos neste momento para garantir que tudo está funcionando (e, no caso do HOTP, para garantir que o contador esteja sincronizado, mas falaremos mais sobre isso mais tarde).

Feito isso, o autenticador é configurado para fornecer códigos para essa conta. Na verdade, usar o autenticador funciona da seguinte maneira:

1. Quando solicitado um código, o autenticador consulta primeiro um contador interno. Para HOTP, este é um contador simples que é incrementado em um para cada código gerado para uma determinada conta. Para TOTP, é um carimbo de data/hora contado em segundos desde a época do UNIX.
2. Depois de determinar o contador, o autenticador recupera o segredo, combina-o com o contador e, em seguida, gera um código de autenticação de mensagem com hash para a combinação (implementações típicas usam SHA-1 para isso, mas qualquer algoritmo de hash criptograficamente seguro pode ser usado).
3. Se o TOTP estiver sendo usado, o tempo limite do código atual será exibido e, quando expirar, um novo será gerado.

O servidor faz exatamente a mesma coisa para verificar o código.

É importante observar que, uma vez configurado o autenticador, não há comunicação entre o autenticador e o servidor, exceto quando o usuário digita um código quando solicitado, e não há nenhuma comunicação entre o servidor e o autenticador. Este aspecto é uma parte extremamente importante do motivo pelo qual HOTP e TOTP são geralmente considerados seguros, mas SMS ou 2FA baseado em e-mail geralmente não são.

Além disso, é importante observar que tanto o HOTP quanto o TOTP têm algumas limitações inerentes:

• O HOTP exige que o cliente e o servidor mantenham seus contadores sincronizados. Se eles ficarem fora de sincronia (geralmente porque o usuário gera vários códigos sem usá-los), os códigos param de funcionar. Muitos servidores irão lidar com o caso específico do cliente ficar à frente do servidor automaticamente até algum limite , e avançar o contador para o que quer que seja para o código que foi usado, mas isso ainda requer manipulação, e adiciona uma sobrecarga de processamento não trivial no servidor.
• O TOTP exige que o cliente e o servidor geralmente concordem relativamente bem com o horário e que o usuário use o código antes que ele expire. O primeiro problema geralmente é resolvido para qualquer cliente conectado à Internet, mas o segundo é complicado e geralmente significa que o servidor aceitará um código por algum tempo após ele expirar. A natureza baseada no tempo também significa que você precisa de um bloqueio para evitar a reutilização de código, o que limita funcionalmente a taxa de tentativas de autenticação bem-sucedidas (isso não é realmente um problema para qualquer caso de uso do mundo real e, na verdade, melhora um pouquinho a segurança, mas é uma limitação).

Alguns sistemas usam uma abordagem semelhante ao TOTP ou HOTP, mas com um algoritmo diferente, geralmente por motivos legados. Um exemplo particularmente proeminente é o 'Steam Guard Mobile Authenticator' da Valve, que usa TOTP funcionalmente, mas automatiza totalmente a configuração e usa um mecanismo diferente para derivar o código da saída do algoritmo hash.

Para referência, a outra grande implementação segura de 2FA que está em uso generalizado é o FIDO2, que funciona de maneira um pouco diferente, mas ainda depende do conceito de o usuário provar sua identidade fazendo algo que somente ele deveria ser capaz de fazer (em vez de gerar códigos , o FIDO2 envolve assinar digitalmente um desafio de autenticação usando uma chave que foi previamente configurada com o servidor, que é tecnicamente mais segura que o TOTP por alguns motivos).