A autenticação básica tem uma série de desvantagens, uma das quais é que o nome de usuário e a senha são passados ​​de forma clara a cada solicitação. Isso é claramente inseguro em HTTP, mas é um pouco menos vulnerável em HTTPS. No entanto, como as credenciais são enviadas com cada solicitação, ainda é pior do que qualquer outro método (incluindo resumo) que não tenha essa limitação. O principal motivo é que agora cada solicitação pode ser um alvo para roubo de credencial de texto não criptografado, não apenas uma solicitação de login inicial. Na maioria dos sistemas, após o login, o máximo que um invasor pode esperar recuperar é uma sessão ou token de autenticação. Com a autenticação básica, qualquer solicitação é uma oportunidade de roubar a senha do usuário. Isso não é ideal.

A autenticação resumida é um pouco melhor, pois envia um resumo MD5 de vários bits, incluindo o nome de usuário, a senha e um nonce (entre outros valores) e não as credenciais de texto não criptografado ... Uma senha não pode ser extraída de um resumo capturado.

Com a autenticação HTTP (em qualquer forma), você também depende do cliente para fornecer a experiência do usuário de autenticação, que pode ter seus próprios problemas e, portanto, precisa ser bem testado com os clientes que você espera que sejam usando seu aplicativo. No passado, por exemplo, eu vi navegadores específicos falharem na autenticação por causa de certos caracteres especiais em uma senha, por exemplo. Com a UX de autenticação baseada em aplicativo, você tem controle sobre isso. Com a autenticação HTTP, você não precisa.

Outro ataque (e muito pequeno) é que, se você exibir conteúdo gerado pelo usuário e hospedado externamente em seu site, estará se abrindo para ataques 401 de phishing muito sutis. Como seus usuários estão acostumados com o cromo do cliente para autenticação HTTP, eles não necessariamente perceberão se receberem um prompt de autenticação em seu site para um domínio ligeiramente diferente. Dependendo do seu aplicativo, isso pode não ser uma ameaça válida, mas certamente é algo a se considerar se você seguir a rota de autenticação HTTP.

Além dos outros pontos mencionados, outra desvantagem significativa da Autenticação Básica HTTP (versus, digamos, login baseado em formulários) é que ela não tem o conceito de "logout". Depois que o usuário insere suas credenciais, o navegador as armazena internamente para enviar com cada solicitação subsequente. Isso significa que você não pode ter um tempo limite ou botão / link "Logout" para encerrar a sessão. Se o usuário quiser evitar a possibilidade de outra pessoa usar sua sessão (por exemplo, no caso de um computador compartilhado), ele deve se lembrar de fechar o navegador.

Para mais leituras: https: / /stackoverflow.com/questions/233507/how-to-log-out-user-from-web-site-using-basic-authentication

A autenticação de acesso básico por HTTPS tem vantagens claras sobre a autenticação de acesso Digest por HTTP.

Mesmo com a autenticação de acesso resumido, você pode armazenar suas senhas com hash de um sal exclusivo (domínio + nome de usuário), mas primeiro este sal pode ser adivinhado (isso torna os ataques contra usuários únicos e pequenos grupos mais fáceis) e, em segundo lugar, você não pode usar bcrypt , scrypt ou PBKDF2 para tornar a computação de hash mais difícil. Além disso, se você escolheu armazenar os hashes em um formato não recuperável (o que você deve fazer!), Você não pode alterar o reino sem exigir uma senha de usuário clara.

Em SASL , autenticação de acesso digest até foi marcada como histórica pela IETF. Para SASL, eles tinham uma alternativa ( SCRAM, claramente exigindo SASLPrep para normalização de caracteres, por exemplo) que poderiam recomendar para uso. Infelizmente, o SCRAM para HTTP nunca passou no status de rascunho (observe que, com o SCRAM, os sais do usuário também não são secretos. O invasor pode abusar do mecanismo de login para obter sais para todos os usuários que desejar).

A autenticação Digest de acesso pode dar uma falsa sensação de segurança . Se o invasor conseguir capturar um login bem-sucedido, ele pode montar um ataque de força bruta contra a senha. username , realm e nonce são todos valores conhecidos pelo invasor.

Usar HTTP não criptografado é, com ou sem Digest autenticação de acesso, não imune a MITM. O invasor pode não ser capaz de capturar a senha, mas pode capturar cookies de sessão e modificar o conteúdo ou se passar pelo usuário.

Com a autenticação de acesso resumido, a autenticação é especificada apenas para login, mas não para configuração de conta. Você tem que fazer a configuração da conta da "maneira usual". Mesmo que seu código seja inteligente e envie apenas o hash interno para evitar que a senha seja transportada em texto não criptografado, ele pode ser modificado pelo invasor para retransmiti-lo a eles. No entanto, este grave problema existe apenas uma vez, no momento do registro . Supondo que o usuário efetue login em apenas uma pequena quantidade de máquinas, você pode obter segurança semelhante usando TACK para HTTPS. Isso permite que o navegador do usuário autorize apenas o certificado obtido na primeira conexão com o site. Portanto, apenas a primeira conexão permanece exposta ao possível MITM, assim como com a autenticação de acesso digest.