基本身份验证有许多缺点，其中之一是用户名和密码在每个请求中都以明文形式传递。这在 HTTP 下显然是不安全的，但在 HTTPS 下更不容易受到攻击。但是，由于每次请求都会提交凭据，因此它仍然比没有此限制的任何其他方法（包括摘要）更糟糕。主要原因是现在每个请求都可能成为明文凭据盗窃的目标，而不仅仅是初始登录请求。在大多数系统中，登录后，攻击者最希望检索到的就是会话或身份验证令牌。使用基本身份验证，任何请求都是窃取用户密码的机会。这并不理想。

Digest auth 更好一些，因为它发送一些不同位的 MD5 摘要，包括用户名、密码和随机数（以及其他值），而不是明文凭据......无法从捕获的摘要中提取密码。

使用 HTTP 身份验证（以任何形式），您还依赖客户端来提供身份验证用户体验，这可能有其自身的问题，因此需要使用您希望使用您的应用程序的客户端进行良好的测试。例如，在过去，我曾看到特定浏览器由于密码中的某些特殊字符而无法进行身份验证。使用基于应用程序的身份验证 UX，您可以控制它。使用 HTTP 身份验证，您不需要。

另一种攻击（而且是非常轻微的攻击）是，如果您在网站上显示用户生成的、外部托管的内容，您就会面临非常微妙的 401 网络钓鱼攻击。由于您的用户习惯于使用客户端的 chrome 进行 HTTP 身份验证，因此如果他们在您的站点上收到针对稍微不同的域的身份验证提示，他们不一定会注意到。根据您的应用程序，这可能根本不是一个有效的威胁，但如果您使用 HTTP 身份验证路线，这肯定是需要考虑的事情。

除了提到的其他几点之外，HTTP 基本身份验证（相对于基于表单的登录）的另一个重大缺点是它没有“注销”的概念。一旦用户输入了他们的凭据，浏览器就会将它们存储在内部，以便与每个后续请求一起发送。这意味着您不能使用超时或“注销”按钮/链接来结束会话。如果用户想要避免其他人使用他们的会话的可能性（例如在共享计算机的情况下），他们必须记住退出浏览器。

更多阅读：https ://stackoverflow.com/questions/233507/how-to-log-out-user-from-web-site-using-basic-authentication

基于 HTTPS 的基本访问身份验证比基于 HTTP 的摘要式访问身份验证具有明显的优势。

即使使用摘要访问身份验证，您实际上也可以使用唯一的盐（领域 + 用户名）存储您的密码，但首先这种盐是可猜测的（这使得对单个用户和小组的攻击更容易），其次您不能使用bcrypt，scrypt或PBKDF2使哈希计算更难。此外，如果您选择以不可恢复的格式存储哈希值（您应该这样做！），您无法在不要求清除用户密码的情况下更改领域。

在SASL中，摘要访问身份验证甚至已被IETF 标记为历史性的。对于 SASL，他们有一个替代方案（例如 SCRAM，明确要求 SASLPrep 进行字符规范化），他们可以推荐使用。不幸的是，HTTP 的 SCRAM从未通过草案状态（请注意，使用 SCRAM，用户的盐也不是秘密的。攻击者可以滥用登录机制为他们想要的每个用户获取盐）。

摘要访问身份验证可能给人一种虚假的安全感。如果攻击者可以捕获成功登录，他可以对密码进行暴力攻击。username，realm并且nonce都是攻击者的已知值。

使用未加密的 HTTP，不管有没有 Digest 访问身份验证，都不能免受 MITM 的影响。攻击者可能无法捕获密码，但他们可以捕获会话 cookie、修改内容或冒充用户。

使用摘要访问身份验证仅指定用于登录，而不用于帐户设置。您必须以“通常的方式”进行帐户设置。即使您的代码很智能并且它只发送内部哈希以防止密码以明文形式传输，攻击者也可以对其进行修改以将其转发给他们。然而，这个严重的问题只存在一次，在注册时。假设用户仅从少量机器登录，您可以使用TACK for HTTPS 实现类似的安全性。这允许用户的浏览器仅授权它在第一次连接到站点时获得的证书。所以只有第一个连接仍然暴露给可能的 MITM，就像摘要访问身份验证一样。