Resumo

  • O RFC 1938 testava uma resposta x calculando H(x); se o resultado fosse o verificador armazenado, aceitava x e passava a armazená-lo como nova referência.
  • O sucesso consumia a resposta. Por isso, atualização atômica, defesa contra sessões concorrentes, esgotamento e reinicialização faziam parte da semântica de segurança.
  • A frase secreta não atravessava a rede, mas o protocolo não protegia a sessão nem resolvia ataques ativos em geral; HOTP e TOTP usariam outros fatores móveis.

O login que apaga sua própria condição de sucesso

O ponto mais interessante do RFC 1938 aparece depois da comparação. O servidor recebe x, calcula H(x) e confere com o verificador guardado. Havendo igualdade, aceita. Em seguida, grava x no lugar do valor antigo. Uma cópia capturada de x, apresentada mais tarde, só consegue produzir o verificador anterior; a referência atual já é outra.

O registro do RFC Editor identifica o documento de N. Haller e C. Metz como Proposed Standard de maio de 1996, depois tornado obsoleto pelo RFC 2289. O rótulo organiza a sucessão normativa. A contribuição histórica está em mostrar que “uso único” é um comportamento de estado, não uma propriedade visível do código digitado.

A pessoa guarda uma frase secreta e usa uma semente não secreta. O gerador combina ambas e repete uma função hash unidirecional. Em profundidade N, entrega primeiro H^N(S), depois H^(N-1)(S). O servidor mantém o último verificador de 64 bits e a posição da sequência, não a frase secreta. Saber um elo permite andar para o passado já consumido, não calcular o próximo elo necessário.

O desenho evoluiu do S/KEY da Bellcore documentado no RFC 1760. A ameaça era a escuta passiva de logins com senha reutilizável. Uma observação deixava de comprar acessos futuros depois que o usuário legítimo avançasse a cadeia.

Não armazenar o segredo inicial, porém, não significa operar sem estado. O verificador muda e precisa sobreviver a falhas com uma cronologia única. Backup antigo, réplica atrasada e gravação duplicada podem alterar o significado de uma resposta.

Palavras legíveis, bits precisos

O desafio informava algoritmo, número da sequência e semente, como em otp-md5 487 dog2. MD5 era obrigatório, SHA recomendado e MD4 permitido. Os lados precisavam concordar; compatibilidade com o algoritmo mais fraco podia limitar a segurança de todos.

Para tornar 64 bits digitáveis, seis palavras eram escolhidas de um dicionário de 2.048 entradas. Cada palavra representava 11 bits, totalizando 66. Os dois bits extras funcionavam como verificação de erro de entrada e decodificação. Não formavam um novo fator de autenticação, e o significado linguístico das palavras não acrescentava segredo.

O servidor deveria aceitar a codificação padrão por palavras e hexadecimal, além de preferencialmente reconhecer uma forma com dicionário alternativo. Maiúsculas, separação e normalização eram, portanto, detalhes de interoperabilidade. Uma interface podia corromper uma prova válida antes de ela chegar ao hash.

Duas requisições não podem consumir a mesma unidade

O documento descreve um invasor que ouve quase toda a frase de seis palavras, adivinha o restante e corre para chegar primeiro. O servidor conforme precisa se defender. Bloquear sessões de autenticação simultâneas da mesma conta é uma opção, desde que haja timeout para impedir que o bloqueio se transforme em negação de serviço permanente.

Há também a corrida entre processos legítimos. Se dois trabalhadores leem o mesmo verificador antigo, validam x e abrem sessões antes de atualizar o registro, um único item consumível gera dois sucessos. A função hash funcionou; a transação falhou. Comparação e avanço devem ser atômicos ou rigorosamente serializados.

A cadeia termina. O número da sequência mede estoque, e o estoque exige renovação. A nova inicialização precisa alterar a semente ou a frase secreta; repetir ambas reproduz valores que podem ter sido vistos. Enviar a frase secreta em texto aberto para consertar a conta elimina a proteção que justificou o sistema.

Uma recomendação podia exigir um OTP antigo para autorizar a instalação da nova cadeia. No contador um, gastar o último OTP para entrar pode deixar o usuário sem credencial para renovar. Operar antes de zero não é simples conveniência: é preservar a disponibilidade criada pelo modelo.

O que o sucessor manteve — e o que não prometeu

A página do RFC 2289 registra o Proposed Standard de fevereiro de 1998 como substituto. O RFC 2289 preserva a cadeia descendente, acrescenta vetores de teste e melhora orientações. Ao recomendar IPsec contra sequestro de conexão TCP, ele expõe uma fronteira: a prova de login não torna confidencial ou íntegra toda a sessão.

Padrões posteriores movimentam estado de modo distinto. O HOTP usa segredo compartilhado e contador crescente; o validador pode procurar adiante para ressincronizar e avança após o sucesso. O TOTP emprega uma janela temporal como fator móvel de HOTP e exige que um valor já aceito não seja reutilizado no mesmo passo de tempo. Compará-los é útil, mas não demonstra que descendem do S/KEY.

Todos mostram, por caminhos próprios, que validar não é perguntar apenas se os números batem. É definir qual estado vale, que distância é tolerável, o que o sucesso consome e como instâncias distribuídas concordam.

O alcance da prova continua restrito. O RFC 1938 não oferece privacidade nem proteção genérica contra ataques ativos ou engenharia social. O aceite relaciona a resposta ao estado de uma conta configurada. Não prova autorização de comando, execução concluída, acesso duradouro, proteção da conversa seguinte ou identidade civil da pessoa.

O mecanismo por trás do símbolo

A primazia do código em execução de Heng Lu oferece um teste exigente: a especificação pode dizer “uma vez”, mas só a execução revela o que ocorre quando um processo cai, uma réplica atrasa ou um reset restaura o passado.

Uma especificação inicial mínima pode fixar o suficiente: cadeia, desafio, representações, teste e avanço. A implementação local continua aberta, mas não pode mudar o invariante que impede dois sucessos com a mesma unidade.

Separar as camadas da realidade evita atribuir poder mágico ao nome “senha de uso único”. A realidade operacional inclui verificador gravado, mutação atômica, política de concorrência, sequência finita e autoridade de reinicialização. Quando as camadas divergem, a resposta pode estar matematicamente certa e historicamente errada.

O legado do RFC 1938 é este: uma prova pode mudar o ambiente em que a próxima prova será julgada. Nesse caso, autenticar deixa de ser leitura. Torna-se uma escrita que precisa de dono, ordem e memória.

Fontes

  1. RFC Editor — registro atual do RFC 1938
  2. RFC 1938 — A One-Time Password System
  3. RFC 1760 — The S/KEY One-Time Password System
  4. RFC Editor — registro atual do RFC 2289
  5. RFC 2289 — A One-Time Password System
  6. RFC 4226 — HOTP
  7. RFC 6238 — TOTP
  8. Heng Lu — Running-Code Primacy
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  10. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile