Autenticação de acesso Digest - Digest access authentication

HTTP
Métodos de solicitação
Campos de cabeçalho
Códigos de status de resposta
Métodos de controle de segurança de acesso
Vulnerabilidades de segurança

A autenticação Digest de acesso é um dos métodos acordados que um servidor da web pode usar para negociar credenciais, como nome de usuário ou senha, com o navegador da web de um usuário . Isso pode ser usado para confirmar a identidade de um usuário antes de enviar informações confidenciais, como o histórico de transações bancárias online. Ele aplica uma função hash ao nome de usuário e senha antes de enviá-los pela rede. Em contraste, a autenticação de acesso básico usa a codificação Base64 facilmente reversível em vez de hash, tornando-a insegura, a menos que seja usada em conjunto com TLS .

Tecnicamente, a autenticação digest é um aplicativo de hash criptográfico MD5 com o uso de valores nonce para evitar ataques de repetição . Ele usa o protocolo HTTP .

Visão geral

A autenticação Digest de acesso foi originalmente especificada pelo RFC 2069 ( uma extensão para HTTP: Digest Access Authentication ). RFC 2069 especifica aproximadamente um esquema de autenticação digest tradicional com segurança mantida por um valor nonce gerado pelo servidor . A resposta de autenticação é formada da seguinte forma (onde HA1 e HA2 são nomes de variáveis ​​de string): 

HA1 = MD5(username:realm:password)
HA2 = MD5(method:digestURI)
response = MD5(HA1:nonce:HA2)

Um hash MD5 é um valor de 16 bytes. Os valores HA1 e HA2 usados ​​no cálculo da resposta são a representação hexadecimal (em minúsculas) dos hashes MD5, respectivamente.

O RFC 2069 foi posteriormente substituído pelo RFC 2617 ( Autenticação HTTP: Autenticação de Acesso Básico e Digest ). O RFC 2617 introduziu vários aprimoramentos de segurança opcionais para digerir a autenticação; "qualidade de proteção" (qop) , contador de nonce incrementado pelo cliente e um nonce aleatório gerado pelo cliente. Esses aprimoramentos são projetados para proteger contra, por exemplo, criptoanálise de ataque de texto simples escolhido .

Se o valor da diretiva do algoritmo for "MD5" ou não especificado, então HA1 é 

HA1 = MD5(username:realm:password)

Se o valor da diretiva do algoritmo for "MD5-sess", então HA1 é 

HA1 = MD5(MD5(username:realm:password):nonce:cnonce)

Se o valor da diretiva qop for "auth" ou não for especificado, HA2 é 

HA2 = MD5(method:digestURI)

Se o valor da diretiva qop for "auth-int", então HA2 é 

HA2 = MD5(method:digestURI:MD5(entityBody))

Se o valor da diretiva qop for "auth" ou "auth-int", calcule a resposta da seguinte maneira: 

response = MD5(HA1:nonce:nonceCount:cnonce:qop:HA2)

Se a diretiva qop não for especificada, calcule a resposta da seguinte maneira: 

response = MD5(HA1:nonce:HA2)

O acima mostra que quando qop não é especificado, o padrão RFC 2069 mais simples é seguido.

Em setembro de 2015, o RFC 7616 substituiu o RFC 2617 adicionando 4 novos algoritmos: "SHA-256", "SHA-256-sess", "SHA-512-256" e "SHA-512-256-sess". A codificação é equivalente aos algoritmos "MD5" e "MD5-sess", com a função de hash MD5 substituída por SHA-256 e SHA-512-256 . No entanto, a partir de julho de 2021, nenhum dos navegadores populares, incluindo Firefox e Chrome, oferece suporte a SHA-256 como função hash. Em outubro de 2021, o Firefox 93 oferece suporte oficial aos algoritmos "SHA-256" e "SHA-256-sess" para autenticação digest. No entanto, o suporte para algoritmos "SHA-512-256", "SHA-512-256-sess" e hashing de nome de usuário ainda está faltando.

Impacto da segurança MD5 na autenticação digest

Os cálculos MD5 usados ​​na autenticação HTTP digest têm a intenção de ser " unilateral ", o que significa que deve ser difícil determinar a entrada original quando apenas a saída é conhecida. Se a senha em si for muito simples, no entanto, então pode ser possível testar todas as entradas possíveis e encontrar uma saída correspondente (um ataque de força bruta ) - talvez auxiliado por um dicionário ou lista de pesquisa adequada , que para MD5 é prontamente acessível.

O esquema HTTP foi projetado por Phillip Hallam-Baker no CERN em 1993 e não incorpora melhorias subsequentes nos sistemas de autenticação, como o desenvolvimento de código de autenticação de mensagem hash com chave ( HMAC ). Embora a construção criptográfica usada seja baseada na função hash MD5, em 2004 geralmente se acreditava que os ataques de colisão não afetavam os aplicativos em que o texto simples (ou seja, a senha) não era conhecido. No entanto, as reivindicações em 2006 também causaram dúvidas sobre outros aplicativos MD5. Até agora, no entanto, os ataques de colisão MD5 não demonstraram representar uma ameaça à autenticação digerida, e a RFC 2617 permite que os servidores implementem mecanismos para detectar alguns ataques de colisão e reprodução .

Considerações de autenticação HTTP digest

Vantagens

A autenticação HTTP digest foi projetada para ser mais segura do que os esquemas de autenticação digest tradicionais, por exemplo "significativamente mais forte do que (por exemplo) CRAM-MD5 ..." (RFC 2617).

Alguns dos pontos fortes de segurança da autenticação HTTP digest são:

  • A senha não é enviada para o servidor.
  • A senha não é usada diretamente no resumo, mas HA1 = MD5 (nome de usuário: domínio: senha). Isso permite que algumas implementações (por exemplo, JBoss ) armazenem HA1 em vez da senha de texto simples (no entanto, veja as desvantagens desta abordagem)
  • O cliente nonce foi introduzido no RFC 2617, o que permite ao cliente evitar ataques de texto simples escolhido , como as tabelas de arco-íris que poderiam ameaçar os esquemas de autenticação digest
  • O nonce do servidor pode conter carimbos de data / hora. Portanto, o servidor pode inspecionar atributos nonce enviados por clientes, para evitar ataques de repetição
  • O servidor também tem permissão para manter uma lista de valores de nonce do servidor recentemente emitidos ou usados ​​para evitar a reutilização
  • Isso evita o Phishing porque a senha simples nunca é enviada a nenhum servidor, seja o servidor correto ou não. (Os sistemas de chave pública dependem da capacidade do usuário de verificar se o URL está correto.)

Desvantagens

Existem várias desvantagens na autenticação de acesso condensado:

  • O site não tem controle sobre a interface do usuário apresentada ao usuário final.
  • Muitas das opções de segurança no RFC 2617 são opcionais. Se a qualidade de proteção (qop) não for especificada pelo servidor, o cliente irá operar em um modo RFC 2069 legado com segurança reduzida
  • A autenticação Digest de acesso é vulnerável a um ataque man-in-the-middle (MITM) . Por exemplo, um invasor MITM poderia dizer aos clientes para usar a autenticação de acesso básico ou o modo de autenticação de acesso digest RFC2069 legado. Para estender isso ainda mais, a autenticação de acesso digest não fornece nenhum mecanismo para os clientes verificarem a identidade do servidor
  • Um servidor pode armazenar HA1 = MD5 (nome de usuário: domínio: senha) em vez da própria senha. No entanto, se o HA1 armazenado vazar, um invasor pode gerar respostas válidas e acessar documentos no reino tão facilmente como se tivesse acesso à própria senha. A tabela de valores HA1 deve, portanto, ser protegida com a mesma segurança que um arquivo contendo senhas de texto simples.
  • A autenticação de acesso resumido evita o uso de um hash de senha forte (como bcrypt ) ao armazenar senhas (uma vez que a senha ou o nome de usuário digerido, domínio e senha devem ser recuperáveis)

Além disso, como o algoritmo MD5 não é permitido em FIPS , a autenticação HTTP Digest não funcionará com módulos criptográficos certificados por FIPS.

Protocolos de autenticação alternativos

De longe, a abordagem mais comum é usar um protocolo de texto não criptografado de autenticação baseado em formulário HTTP + HTML ou, mais raramente, autenticação de acesso básico . Esses fracos protocolos de texto não criptografado usados ​​junto com a criptografia de rede HTTPS resolvem muitas das ameaças que a autenticação digest de acesso foi projetada para prevenir. No entanto, esse uso de HTTPS depende do usuário final para validar com precisão se está acessando o URL correto a cada vez, para evitar o envio de sua senha a um servidor não confiável, o que resulta em ataques de phishing . Os usuários geralmente não conseguem fazer isso, e é por isso que o phishing se tornou a forma mais comum de violação de segurança.

Alguns protocolos de autenticação fortes para aplicativos baseados na web que são usados ​​ocasionalmente incluem:

Exemplo com explicação

O exemplo a seguir foi fornecido originalmente no RFC 2617 e é expandido aqui para mostrar o texto completo esperado para cada solicitação e resposta . Observe que apenas a qualidade "auth" (autenticação) do código de proteção é coberta - desde abril de 2005, apenas os navegadores Opera e Konqueror são conhecidos por oferecer suporte a "auth-int" (autenticação com proteção de integridade). Embora a especificação mencione o HTTP versão 1.1, o esquema pode ser adicionado com êxito a um servidor da versão 1.0, conforme mostrado aqui.

Esta transação típica consiste nas seguintes etapas:

  1. O cliente pede uma página que requer autenticação, mas não fornece um nome de usuário e senha. Normalmente, isso ocorre porque o usuário simplesmente inseriu o endereço ou seguiu um link para a página.
  2. O servidor responde com o código de resposta 401 "Não autorizado" , fornecendo o domínio de autenticação e um valor de uso único gerado aleatoriamente, denominado nonce .
  3. Nesse ponto, o navegador apresentará o domínio de autenticação (normalmente uma descrição do computador ou sistema que está sendo acessado) ao usuário e solicitará um nome de usuário e uma senha. O usuário pode decidir cancelar neste momento.
  4. Depois que um nome de usuário e uma senha são fornecidos, o cliente reenvia a mesma solicitação, mas adiciona um cabeçalho de autenticação que inclui o código de resposta.
  5. Neste exemplo, o servidor aceita a autenticação e a página é retornada. Se o nome de usuário for inválido e / ou a senha estiver incorreta, o servidor pode retornar o código de resposta "401" e o cliente solicitará ao usuário novamente.
Solicitação do cliente (sem autenticação)
GET /dir/index.html HTTP/1.0
Host: localhost

(seguido por uma nova linha , na forma de um retorno de carro seguido por uma alimentação de linha ).

Resposta do servidor
HTTP/1.0 401 Unauthorized
Server: HTTPd/0.9
Date: Sun, 10 Apr 2014 20:26:47 GMT
WWW-Authenticate: Digest realm="testrealm@host.com",
                        qop="auth,auth-int",
                        nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                        opaque="5ccc069c403ebaf9f0171e9517f40e41"
Content-Type: text/html
Content-Length: 153

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" />
    <title>Error</title>
  </head>
  <body>
    <h1>401 Unauthorized.</h1>
  </body>
</html>
Solicitação do cliente (nome de usuário "Mufasa", senha "Circle Of Life")
GET /dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username="Mufasa",
                     realm="testrealm@host.com",
                     nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                     uri="/dir/index.html",
                     qop=auth,
                     nc=00000001,
                     cnonce="0a4f113b",
                     response="6629fae49393a05397450978507c4ef1",
                     opaque="5ccc069c403ebaf9f0171e9517f40e41"

(seguido por uma linha em branco, como antes).

Resposta do servidor
HTTP/1.0 200 OK
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:27:03 GMT
Content-Type: text/html
Content-Length: 7984

(seguido por uma linha em branco e texto HTML da página restrita).

O valor de "resposta" é calculado em três etapas, como segue. Onde os valores são combinados, eles são delimitados por dois pontos.

  1. O hash MD5 do nome de usuário, domínio de autenticação e senha combinados é calculado. O resultado é conhecido como HA1.
  2. O hash MD5 do método combinado e URI de resumo é calculado, por exemplo, de "GET"e "/dir/index.html". O resultado é conhecido como HA2.
  3. O hash MD5 do resultado HA1 combinado, nonce do servidor (nonce), contador de solicitação (nc), nonce do cliente (cnonce), qualidade do código de proteção (qop) e resultado HA2 é calculado. O resultado é o valor de "resposta" fornecido pelo cliente.

Uma vez que o servidor possui as mesmas informações que o cliente, a resposta pode ser verificada executando o mesmo cálculo. No exemplo fornecido acima, o resultado é formado da seguinte forma, onde MD5()representa uma função usada para calcular um hash MD5 , as barras invertidas representam uma continuação e as aspas mostradas não são usadas no cálculo.

A conclusão do exemplo fornecido na RFC 2617 fornece os seguintes resultados para cada etapa. 

   HA1 = MD5( "Mufasa:testrealm@host.com:Circle Of Life" )
       = 939e7578ed9e3c518a452acee763bce9

   HA2 = MD5( "GET:/dir/index.html" )
       = 39aff3a2bab6126f332b942af96d3366

   Response = MD5( "939e7578ed9e3c518a452acee763bce9:\
                    dcd98b7102dd2f0e8b11d0f600bfb0c093:\
                    00000001:0a4f113b:auth:\
                    39aff3a2bab6126f332b942af96d3366" )
            = 6629fae49393a05397450978507c4ef1

Nesse ponto, o cliente pode fazer outra solicitação, reutilizando o valor do nonce do servidor (o servidor apenas emite um novo nonce para cada resposta "401" ), mas fornecendo um novo nonce do cliente (cnonce). Para solicitações subsequentes, o contador de solicitação hexadecimal (nc) deve ser maior que o último valor usado - caso contrário, um invasor poderia simplesmente " reproduzir " uma solicitação antiga com as mesmas credenciais. Cabe ao servidor garantir que o contador aumente para cada um dos valores de nonce que ele emitiu, rejeitando quaisquer solicitações incorretas de forma adequada. Obviamente, alterar o método, URI e / ou valor do contador resultará em um valor de resposta diferente.

O servidor deve lembrar os valores nonce que gerou recentemente. Ele também pode se lembrar quando cada valor de nonce foi emitido, expirando-os após um determinado período de tempo. Se for usado um valor expirado, o servidor deve responder com o código de status "401" e adicionar stale=TRUEao cabeçalho de autenticação, indicando que o cliente deve reenviar com o novo nonce fornecido, sem solicitar ao usuário outro nome de usuário e senha.

O servidor não precisa manter nenhum valor expirado de nonce - ele pode simplesmente presumir que qualquer valor não reconhecido expirou. Também é possível que o servidor permita que cada valor de nonce seja retornado apenas uma vez, embora isso force o cliente a repetir todas as solicitações. Observe que expirar um nonce do servidor imediatamente não funcionará, pois o cliente nunca teria a chance de usá-lo.

O arquivo .htdigest

.htdigest é um arquivo simples usado para armazenar nomes de usuário, domínio e senhas para autenticação digest do servidor HTTP Apache . O nome do arquivo é fornecido na configuração .htaccess e pode ser qualquer coisa, mas ".htdigest" é o nome canônico. O nome do arquivo começa com um ponto, porque a maioria dos sistemas operacionais do tipo Unix considera qualquer arquivo que comece com um ponto como oculto. Este arquivo geralmente é mantido com o comando shell "htdigest", que pode adicionar e atualizar usuários e codificar corretamente a senha para uso.

O comando "htdigest" é encontrado no pacote apache2-utils em sistemas de gerenciamento de pacotes dpkg e no pacote httpd-tools em sistemas de gerenciamento de pacotes RPM .

A sintaxe do comando htdigest: 

htdigest [ -c ] passwdfile realm username

O formato do arquivo .htdigest: 

user1:Realm:5ea41921c65387d904834f8403185412
user2:Realm:734418f1e487083dc153890208b79379

Autenticação de resumo SIP

O protocolo de iniciação de sessão (SIP) usa basicamente o mesmo algoritmo de autenticação de resumo. Ele é especificado pelo RFC 3261.

Implementação do navegador

A maioria dos navegadores implementou substancialmente a especificação, alguns impedindo certos recursos, como a verificação de autenticação ou o algoritmo MD5-sess. Se o servidor exigir que esses recursos opcionais sejam tratados, os clientes podem não ser capazes de autenticar (embora observe que mod_auth_digest para Apache também não implementa totalmente o RFC 2617).

Suspensões de uso

Devido às desvantagens da autenticação Digest em comparação com a autenticação Básica sobre HTTPS, ela foi preterida por muitos softwares, por exemplo:

Veja também

Notas

Referências

links externos