Resumo

  • O RFC 2069 impediu que a senha do Basic atravessasse a rede em forma recuperável, mas H(A1) continuou no servidor como um equivalente de senha limitado ao realm.
  • A resposta básica vinculava esse segredo ao nonce, ao método e à URI; não criptografava conteúdo, não cobria automaticamente toda a mensagem e não provava intenção, autorização nem efeito único.
  • Um nonce autocontido podia restringir endereço e tempo sem manter estado. Rejeitar a segunda utilização exigia guardar respostas usadas até a expiração, com custos de memória e coordenação.

A otimização escondida dentro do desafio

No RFC 1945, o Basic enviava usuário e senha em Base64. Era representação, não sigilo. O RFC 2069, de janeiro de 1997, substituiu essa exposição por challenge-response. O cliente calculava uma resposta com a senha e valores da requisição; o observador já não recebia a senha legível. O primeiro HTTP/1.1, RFC 2068, formava o contexto contemporâneo.

O próprio RFC delimitou a vitória. Digest era uma autenticação de acesso fraca, não criptografava o conteúdo e não explicava como a senha inicial fora estabelecida com segurança. Intermediário hostil, servidor falso, senha fraca e replay permaneciam riscos. O registro oficial do RFC 2069 documenta sua posição histórica, não a presença do mecanismo em instalações reais.

O que entra na igualdade

O RFC 2069 especificou MD5, do RFC 1321, e definiu:

A1 = username : realm : password
A2 = Method : request-URI
response = KD(H(A1), nonce : H(A2))

Uma igualdade válida associa material secreto de um realm a um desafio do servidor, um método e uma URI. O servidor também precisa garantir que o uri declarado corresponde ao recurso efetivamente servido, pois um proxy pode alterar a linha de requisição.

Esse conjunto não contém todos os cabeçalhos, não autentica a rota, não cifra corpo ou resposta e não registra o motivo da operação. A resposta não diz se uma pessoa consentiu, se o principal tinha autorização, se a regra de negócio passou ou se a transação foi confirmada uma vez. Para POST e PUT, o RFC ofereceu um digest de entidade separado e opcional, cobrindo corpo e alguns metadados. A opção demonstra que a resposta básica não era uma assinatura integral.

O arquivo de hashes ainda podia agir

O servidor não precisava conhecer a senha clara; usuário e H(A1) bastavam. H(A1) incorpora username:realm:password, portanto um mesmo segredo humano produz verificadores diferentes quando muda o realm. Essa separação reduz a portabilidade direta de um arquivo roubado.

Ela não torna o arquivo inofensivo. A seção de armazenamento do RFC diz que um invasor com H(A1) obtém acesso imediato aos documentos daquele realm sem recuperar a senha. Por isso o arquivo deve ser protegido como se contivesse senhas não criptografadas. “Equivalente de senha” significa exatamente essa capacidade dentro do realm, não a revelação universal da senha original.

Também permanece possível testar senhas fracas fora de linha. A classificação operacional correta pergunta o que a posse do valor permite executar. Uma réplica, um backup ou um serviço auxiliar com H(A1) não guarda apenas uma impressão digital; guarda a capacidade de produzir uma autorização aceitável.

Janela válida versus primeira passagem

O nonce recomendado incluía um hash de IP do cliente, timestamp e chave privada do servidor. Cada nó com a chave poderia recalcular o token e conferir endereço e validade temporal. Não seria necessário registrar cada desafio emitido, vantagem importante para escala e disponibilidade.

Essa construção não mantém histórico. Durante o prazo, uma cópia capturada ainda satisfaz a mesma verificação. O RFC observou que repetir um GET simples costuma ter pouco valor, pois a URI está ligada e o observador já viu o documento. Mas um GET pode acionar código; e replay de POST ou PUT pode criar dados de formulário ou arquivo falsificados.

Para uma aplicação que não aceita replay, o servidor deve usar respostas de uma vez e lembrar os digests já vistos até a expiração do nonce. O resultado forte nasce de armazenamento, busca e expiração. Em vários nós, precisa ainda de coerência ou de roteamento que preserve a autoridade do registro. Um hash correto não fornece sozinho nenhuma dessas garantias.

A evolução esclareceu a dívida

O RFC 2617 substituiu o 2069, conforme sua ficha RFC Editor. Ele acrescentou qop, cnonce e nc. O cliente conta as requisições com o mesmo nonce; o servidor conserva sua própria cópia e reconhece um contador repetido. qop=auth-int também coloca o hash do corpo em A2. Quando qop não aparece, a fórmula antiga continua por compatibilidade — logo, contador e nonce do cliente não eram promessas ocultas do texto de 1997.

O RFC 7616 e sua ficha adicionaram SHA-256 e SHA-512/256 e tornaram MD5 não recomendado. Ainda assim, repetiram que H(A1) roubado dá acesso ao realm e deve ser protegido como senha clara. Também explicaram que agilidade de algoritmo não conserta senha humana fraca e recomendaram HTTPS.

O RFC 9110 ajuda a manter a semântica atual: credenciais autenticadas podem alimentar autorização, mas não são a decisão de autorização nem a confirmação do efeito.

Uma trilha que não pula etapas

Um registro de Digest aceito para POST /ordem sustenta só o primeiro elo: certo nó verificou material secreto, nonce, método e URI. A investigação ainda precisa do modo de cobertura do corpo, do estado anti-replay, do principal mapeado, da política vigente, do identificador da transação e do resultado no sistema responsável.

A Running-Code Primacy de Lu Heng pede prova no sistema em execução, não deferência ao documento. A Minimum Initial Specification separa regra comum de escolhas locais futuras. A fórmula Digest é comum; custódia, duração, estado e autorização são decisões dos operadores.

Sua análise de Reality Layers impede a última substituição: um símbolo válido em uma camada não executa as seguintes. A igualdade matemática é evidência, não mandato sobre intenção ou resultado.

Fontes