Resumo

  • nc é a contagem dos pedidos que o cliente afirma ter enviado com o nonce presente naquele pedido. O servidor precisa manter sua própria cópia para detectar a repetição do valor.
  • O cálculo Digest vincula a contagem ao material derivado da credencial, aos nonces e a partes selecionadas do HTTP. Isso não cria uma identidade global, uma autorização de negócio ou um recibo de execução.
  • Operações relevantes precisam de um identificador persistente e de consulta ao resultado. Um retry pode ser autenticado de forma válida sem demonstrar que a tentativa anterior não produziu efeito.

O começo ordenado que engana

O primeiro pedido com um nonce leva nc=00000001. Os próximos incrementam o valor hexadecimal. Se o servidor guardar a contagem que espera e receber o mesmo valor outra vez, poderá identificar um replay. A sequência é atraente porque parece combinar ordem e prova criptográfica.

O significado normativo é mais estreito. A contagem cobre os pedidos que o cliente diz ter enviado com aquele nonce, incluindo o atual. Não confirma que o servidor admitiu todos eles, que chegaram à mesma instância ou que mudaram o estado da aplicação na ordem exibida. Fora do nonce, o número não é único.

Quando o servidor emite outro nonce, a série recomeça. Outro cliente, realm ou espaço de proteção mantém outra série. Reiniciar em um não apaga a história do negócio. Apenas abre um contexto de autenticação diferente. Por isso, nc pode localizar uma repetição dentro de um diálogo acompanhado, mas não posicionar uma transação no tempo global do serviço.

Até a prova de replay depende de contexto. Oito dígitos isolados no log dizem pouco sem nonce, client nonce, usuário, realm e decisão do servidor. Com esses elementos, o evento explica a camada de autenticação. Ainda não demonstra se houve commit.

A memória que faz o número funcionar

O RFC diz que o servidor detecta a repetição mantendo sua própria cópia da contagem. O valor enviado pelo cliente não é um recibo autônomo. Sua interpretação depende da política que gerou e validou o nonce.

Essa política é específica da implementação. Um nonce é opaco para o cliente e pode ser limitado por tempo, recurso, origem, número de usos ou outra condição. O servidor pode aceitar um nonce uma só vez e lembrar que ele foi gasto. A proteção contra replay imediato aumenta, assim como o custo de estado; pedidos em pipeline podem falhar. Outra opção é manter o nonce por mais tempo e usar nc, preservando boa parte da defesa sem desafiar cada pedido novamente.

Em um cluster, alguém precisa decidir como esse estado sobrevive entre instâncias. Se ele for particionado ou perdido no failover, duas máquinas podem julgar a mesma repetição de modo diferente. Isso altera a capacidade de detectar replay. Não desfaz uma gravação no banco, uma publicação na fila ou uma chamada feita a um terceiro.

O perímetro real do cálculo

Com qop, a resposta Digest usa material derivado da senha, nonce do servidor, nc, client nonce, qop e o hash de A2. Em qop=auth, A2 contém método HTTP e URI. Em qop=auth-int, inclui também o hash do corpo da entidade. O servidor verifica o conhecimento do segredo e consegue detectar certas repetições ou mudanças.

O perímetro não é o HTTP inteiro. Mesmo com auth-int, a maioria dos cabeçalhos fica fora da integridade, e o RFC alerta para alterações por intermediários hostis. Digest também não dá confidencialidade ao restante da troca; a recomendação é usá-lo sobre HTTPS.

Autenticação tampouco substitui autorização. Saber que o solicitante conhece o segredo configurado não decide se ele pode fazer a transferência, remover o registro ou iniciar o deploy. Essa decisão depende do papel, do estado atual e das regras da aplicação.

Rifaat Shekh-Yusef aparece como editor e coautor coletivo do RFC 7616, resultado do consenso da IETF. O nonce count não nasceu nessa revisão: o RFC 2617 já o trazia. O texto de 2015 manteve o mecanismo e acrescentou SHA-256, SHA-512/256, negociação de algoritmo, uso atualizado de qop, userhash e análise de segurança mais clara. Ele próprio avisa que agilidade de algoritmo não elimina ataques de dicionário contra senhas memorizáveis.

Uma confirmação do servidor não é o recibo da aplicação

O campo Authentication-Info pode levar rspauth e repetir cnonce e nc do pedido correspondente. Isso permite autenticação mútua: o servidor demonstra conhecer o segredo do usuário; com auth-int, há integridade limitada na resposta.

Essa confirmação pertence ao plano Digest. Ela não nomeia pagamento, tarefa, commit, reversão ou resultado consultável. Um servidor pode validar a autenticação, entregar o trabalho a outro processo e perder a resposta depois que esse processo efetivou a mudança. O cliente recebe um nonce novo e faz um retry válido. Duas autenticações corretas podem acompanhar duas execuções da mesma intenção.

O controle que falta precisa estar na aplicação. Uma chave de idempotência associa tentativas à mesma operação pretendida. Uma consulta por essa chave informa o resultado após um timeout. O RFC 7616 não define nenhuma das duas; não é correto inventá-las dentro de nc.

Cinco evidências, não uma luz verde

Uma operação consequente deve separar o sucesso da autenticação, a decisão de replay, a autorização da aplicação, a identidade persistente da operação e a pós-condição confirmada. Em alguns casos, também é preciso saber se a resposta chegou ao cliente. Cada registro observa uma fronteira diferente.

Usar bem o nonce count é respeitar essa especialização. O servidor deve proteger o estado que torna a contagem verificável, empregar nonces restritos quando necessário, escolher qop pelo risco e manter HTTPS. Depois, a inferência precisa parar. Um contador de autenticação não vê o livro de negócio e não pode substituí-lo.

Fontes