O que é autenticação digest?

101

Qual é a diferença entre a Autenticação Digest e a Autenticação Básica, exceto o envio de credenciais como texto simples?

digest-authentication

— SoftwareGeek
fonte

Ótima explicação de @Gumbo aqui: stackoverflow.com/a/5288679/591487

— inorganik

Algo que você NUNCA deve usar. Não protege a senha em trânsito e exige que o servidor armazene as senhas de forma simples.

— CodesInChaos

O Digest fornece melhor segurança em trânsito do que a autenticação Básica para tráfego não criptografado , mas é fraco. É MUITO mais seguro usar a autenticação básica em combinação com SSL / TLS, porque dessa forma você também pode manter as senhas criptografadas no servidor.

— rustyx

Respostas:

179

A principal diferença é que não requer o envio do nome de usuário e da senha em texto simples. Ele também é imune a ataques de repetição, pois usa um número único do servidor.

O servidor fornece ao cliente um número de uso único (um nonce) que combina com o nome de usuário, domínio, senha e a solicitação de URI. O cliente executa todos esses campos por meio de um método de hashing MD5 para produzir uma chave hash.

Ele envia essa chave hash para o servidor junto com o nome de usuário e o realm para tentar autenticar.

Do lado do servidor, o mesmo método é usado para gerar uma chave de hash, mas em vez de usar a senha digitada no navegador, o servidor procura a senha esperada para o usuário no banco de dados do usuário. Ele procura a senha armazenada para este nome de usuário, executa o mesmo algoritmo e compara com o que o cliente enviou. Se corresponderem, o acesso é concedido; caso contrário, pode enviar de volta um 401 Não autorizado (nenhum login ou login com falha) ou um 403 Proibido (acesso negado).

A autenticação Digest é padronizada em RFC2617 . Há uma boa visão geral disso na Wikipedia :

Você pode pensar assim:

Cliente faz pedido
O cliente recebe de volta um nonce do servidor e uma solicitação de autenticação 401
O cliente envia de volta a seguinte matriz de resposta (nome de usuário, domínio, gerar_md5_key (nonce, nome de usuário, domínio, URI, senha_given_by_user_to_browser)) (sim, isso é muito simplificado)
O servidor pega o nome de usuário e o domínio (além de saber o URI que o cliente está solicitando) e procura a senha desse nome de usuário. Então ele vai e faz sua própria versão de generate_md5_key (nonce, nome de usuário, reino, URI, senha_I_have_for_this_user_in_my_db)
Ele compara a saída de generate_md5 () que obteve com a que o cliente enviou, se eles correspondem ao cliente enviou a senha correta. Se não corresponderem, a senha enviada estava errada.

— Ian C.
fonte

Bela explicação. O nome de usuário e o pwd são para um usuário do Windows? De onde eles são gerados?

— SoftwareGeek

Eles são tudo o que o usuário digita no navegador. A senha deve corresponder ao que o servidor armazenou para a senha desse usuário. É mais provável que seja algo específico para aquele aplicativo da web e não sua senha do Windows. Depende muito da forma como o aplicativo da web é montado.

— Ian C.

Esta resposta tem 6 anos, mas acho que todos os sistemas cientes de segurança armazenam senhas em formato hash salgado agora. Não existe e não deve haver nenhum método para obter a senha original do banco de dados, tornando impossível a autorização do resumo.

— Ramon de Klein de

Se o hash de resumo de nome de usuário e senha for armazenado em db em vez de senhas simples, ainda será possível usar a autenticação de resumo @RamondeKlein

— karakays

@BlueBockser Acho que karakays significava que em vez de usar uma senha simples, um hash resultante da combinação do nome de usuário e sua senha deveria ser armazenado no servidor ao se inscrever e computado no lado do cliente antes da autenticação. Isso também pode ser feito com apenas um hash da senha.

— logo_writer

Um hash das credenciais é enviado pela rede.

HA1 = MD5(username:realm:password)

A Wikipedia tem um excelente artigo sobre este assunto

— Philip Fourie
fonte

do cliente para o servidor? Você poderia fornecer etapas para a interação? O artigo da Wikipedia é bom, mas preciso de uma melhor explicação ou exemplo.

— SoftwareGeek

Sim, o cliente gera o valor hash e envia para o servidor. O artigo da Wikipedia descreve o protocolo em detalhes, sugiro que você faça referência a ele para obter mais informações.

— Philip Fourie

A única maneira de obter o hash HA1 das credenciais é saber a senha. O servidor conhece HA1, mas não a senha que o gerou. Se HA1 fosse conhecido por um invasor, ele poderia entrar no sistema. Portanto, não é enviado pelo fio. Um hash adicional baseado em nonce, etc. é feito antes de fazer isso, e deve concordar com um cálculo semelhante feito no servidor. Portanto, enquanto o servidor mantiver HA1 privado, o sistema estará seguro.

— Chris Oakley
fonte

Esta é a explicação para a autenticação Digest, em que a senha não é enviada em texto simples (que é o caso da autenticação básica)

— Erik Oppedijk