decodificar chave secreta totp base32
A chave de um app autenticador nunca aparece como bytes crus: ela sempre chega em Base32, o alfabeto A-Z mais 2-7 definido pela seção 6 do RFC 4648. A escolha não é arbitrária. RFC 6238 (TOTP) e RFC 4226 (HOTP, a base do TOTP) definem como essa chave vira um código de 6 dígitos a cada 30 segundos, mas é o Base32 que decide como a chave circula entre servidor, QR code e teclado.
Decodifica para "Hello!" mais 4 bytes (48 65 6c 6c 6f 21 de ad be ef); é o exemplo clássico do RFC, curto demais para proteger uma conta real.
32 caracteres, sem padding: 20 bytes vezes 8 bits dividido por 5 bits por símbolo fecha em exatamente 32, sem sobra, então nenhum "=" é necessário.
Espaços são só apresentação: um decodificador Base32 correto ignora esse agrupamento visual e lê os mesmos 32 símbolos de dados.
Se a outra ponta fala em RFC 4648 sem qualificar, é o alfabeto A-Z2-7 com padding. Use base32hex quando a ordem alfabética do texto codificado precisar acompanhar a ordem numérica dos dados, que é o caso do NSEC3 em DNSSEC. Use Crockford quando o código vai ser lido e digitado por pessoas e você quer detectar erro na hora, com o dígito de verificação. Use z-base-32 quando o valor vai ser ditado em voz alta. Escolher errado não corrompe nada, mas a outra ponta não vai conseguir decodificar.
Porque Base32 é case-insensitive e usa só 32 símbolos sem os pares ambíguos 0/O e 1/I/L, o que importa quando a chave precisa ser digitada manualmente num app, não só escaneada por QR code. Base64 é case-sensitive e inclui + e /, símbolos que complicam a digitação e a leitura em voz alta.
Não. Ela decodifica para apenas 10 bytes, 80 bits, abaixo dos 128 bits que o RFC 4226 exige como mínimo para o segredo compartilhado. É o exemplo didático do próprio RFC, feito para ilustrar a estrutura, não uma chave que um serviço real deveria gerar; serviços sérios geram pelo menos 160 bits (20 bytes).
Porque RFC 6238 define o contador como o horário Unix atual dividido por 30 e truncado para baixo, não um contador incremental como no HOTP puro (RFC 4226). Isso significa que servidor e app chegam ao mesmo código de forma independente, sem sincronizar chamadas entre si, desde que os dois relógios estejam alinhados.
ABCDEFGHIJKLMNOPQRSTUVWXYZ234567Tudo é calculado no seu navegador, inclusive o arquivo carregado e qualquer segredo colado. Nada é enviado para servidor.