TOTP e verificação em duas etapas
O código de seis dígitos que muda a cada meia minuto no aplicativo autenticador não vem do servidor, ele é calculado localmente a partir de um segredo combinado uma única vez no cadastro e do relógio atual, seguindo o algoritmo TOTP padronizado na RFC 6238.
É o resultado da truncagem dinâmica do HMAC-SHA-1 sobre o contador 56.802.240; o código muda no próximo múltiplo de 30 segundos, quando o contador avança para 56.802.241.
Os últimos seis dígitos são idênticos ao código padrão porque os dois vêm da mesma truncagem dinâmica sobre o mesmo HMAC, só mudando quantos dígitos finais são mantidos.
Esse formato de URI, adotado por todo aplicativo autenticador embora não seja uma RFC própria, é o que o QR code de cadastro codifica; qualquer app que leia esse link reconstrói os mesmos parâmetros (segredo, algoritmo, dígitos, período) usados aqui.
TOTP é um esquema de senha de uso único baseado em tempo, definido na RFC 6238. Ele gera um código curto a partir de um segredo compartilhado e do horário atual, código esse que muda a cada período e é usado na autenticação em duas etapas.
Porque o contador do TOTP é o tempo Unix dividido pelo período configurado, 30 segundos por padrão na RFC 6238; a cada vez que esse contador muda de valor inteiro, o HMAC sobre ele muda, e por consequência o código truncado também muda, independente de haver ou não uma tentativa de login em andamento.
Não exatamente: o segredo em base32 (como `JBSWY3DPEHPK3PXP`) é só o dado bruto usado no cálculo HMAC; o QR code codifica esse segredo dentro de uma URI `otpauth://` completa, que também carrega o nome da conta, o emissor, o algoritmo, a quantidade de dígitos e o período, tudo que o app precisa para gerar os mesmos códigos.
Como o TOTP não troca mensagens para se sincronizar, ele depende inteiramente do relógio de cada lado bater dentro de uma janela de tolerância que o verificador aceita, geralmente um ou dois períodos de 30 segundos para trás e para frente; um desvio maior que isso faz até o código correto do usuário ser rejeitado, um problema de sincronização de horário, não de segurança do algoritmo.
Não no mesmo nível: TOTP é simétrico, o servidor guarda o mesmo segredo usado para gerar o código, então quem rouba esse banco de dados consegue gerar códigos válidos para sempre. Uma chave FIDO2/WebAuthn usa um par de chaves assimétrico, e a chave privada nunca sai do dispositivo físico nem é armazenada pelo servidor, o que elimina esse risco específico.
—otpauth://totp/J-Kit:user%40example.com?secret=JBSWY3DPEHPK3PXP&algorithm=SHA1&digits=6&period=30&issuer=J-KitO segredo e os códigos são gerados apenas no navegador com WebCrypto. Nada é enviado a servidores.