Ataques de temporização e comparação de segredos em tempo constante

O que é

Existe um canal lateral de temporização quando o tempo de uma operação depende de dados secretos. O caso clássico é comparar um valor enviado com um segredo armazenado usando a igualdade comum: a comparação retorna assim que um byte difere, de modo que um palpite com o primeiro byte correto leva um pouco mais de tempo do que um com o primeiro byte errado. Medições repetidas eliminam o ruído por média e permitem que um atacante recupere o valor byte a byte. As bibliotecas padrão oferecem comparações cuja duração não depende do conteúdo: hmac.compare_digest, do Python, usa "an approach designed to prevent timing analysis by avoiding content-based short circuiting behaviour" (uma abordagem pensada para impedir a análise de temporização, evitando o curto-circuito baseado no conteúdo); crypto.timingSafeEqual, do Node, compara os bytes subjacentes com um algoritmo de tempo constante e está documentada como adequada para digests HMAC, cookies de autenticação e URLs de capacidade (capability URLs); subtle.ConstantTimeCompare, do Go, leva um tempo que depende dos tamanhos e é independente do conteúdo.

Por que importa

Tudo o que um servidor compara com um segredo é afetado: assinaturas de webhook, chaves de API, tokens de redefinição de senha, identificadores de sessão, tokens CSRF, tags HMAC de cookies assinados. Saber se o vazamento é explorável em uma rede com ruído é uma questão de quantidade de amostras, não de princípio; a função de tempo constante é barata e elimina essa dúvida.

Como aplicar

• Compare todo valor que carrega um segredo com a função de tempo constante da plataforma, nunca com == nem com igualdade de strings, e não busque o registro pelo token em texto puro (WHERE token = ?), já que uma comparação feita pelo banco de dados não é uma comparação em tempo constante; busque por um id não secreto ou por um hash do token e só então compare em tempo constante.
• Atenção à regra do tamanho. As três funções tratam tamanhos diferentes de forma especial: a nota do Python diz que uma diferença de tamanho pode revelar os tamanhos, mas não os valores; o Node lança uma exceção; o Go retorna 0 imediatamente. Compare digests de tamanho fixo, ou hashes das entradas, para que os tamanhos sempre coincidam.
• Mantenha constante o caminho inteiro, não apenas a comparação: quando um nome de usuário não existe, verifique mesmo assim a senha contra um hash fictício, para que "usuário desconhecido" e "senha incorreta" levem o mesmo tempo.
• Armazene no servidor os tokens de portador (bearer tokens) como hashes e compare os hashes; assim, uma tabela vazada também não contém tokens utilizáveis.

Armadilhas

Uma comparação em tempo constante não corrige uma etapa de tempo variável anterior a ela, como um desvio condicional baseado no prefixo do segredo ou um decodificador que rejeita a entrada cedo; a documentação do Node afirma que usar timingSafeEqual não garante que o código ao redor seja seguro quanto à temporização. Limitar a taxa de requisições reduz as amostras do atacante, mas é uma segunda linha de defesa, não um substituto. Um laço de comparação escrito à mão pode ser transformado por um compilador ou runtime de maneiras que reintroduzem uma temporização dependente dos dados; use a função da biblioteca.