基本访问认证安全吗？

Question

使用 Apache，设置一个页面非常简单，该页面使用基本访问身份验证来提示用户输入名称/密码，并以某种方式使用这些凭据来授予该用户访问权限。

假设客户端和服务器之间的连接是安全的，这安全吗？

Answer 1

对基本身份验证的担忧是，凭据以明文形式发送，并且容易受到数据包嗅探，如果使用 TLS/SSL 保护该连接，那么它与使用加密的其他方法一样安全。

Answer 2

这是一个旧线程，我不相信最高投票/选择的答案是正确的。

正如 @Nateowami 所指出的，安全堆栈交换线程概述了基本身份验证的许多问题。

我想指出另一点：如果您正确地进行了密码验证，那么基本身份验证会使您的服务器更容易受到拒绝服务攻击。为什么？过去，人们普遍认为加盐哈希足以进行密码验证。 情况不再是这样了。如今，我们说您需要具有慢速功能，以防止在数据库暴露时（这种情况经常发生）被暴力破解。如果您使用基本身份验证，那么您将迫使您的服务器在每个 API 调用上执行这些缓慢的计算，这会给您的服务器增加沉重的负担。只需使用这种过时的身份验证机制，您就会使其更容易受到 DoS 攻击。

更一般地说，密码比会话具有更高的价值：用户密码的泄露可以无限期地劫持用户的帐户，更不用说由于密码重复使用而劫持用户访问的其他系统的可能性；而用户会话是有时间限制的并且仅限于单个系统。因此，作为纵深防御的考虑，密码等高价值数据如非必要，不应重复使用。基本身份验证是一项过时的技术，应该被弃用。

Answer 3

大多数网站更喜欢 OAuth 而不是 Basic Auth 的原因是 Basic Auth 要求用户在第 3 方应用程序中输入密码。该第三方应用程序必须以明文形式存储密码。撤销访问权限的唯一方法是用户更改密码。但是，这将撤销所有第三方应用程序的访问权限。所以你可以看看这里有什么问题。

另一方面，OAuth 需要 Web 框架。用户在该特定站点本身的登录页面上输入他们的登录信息。然后，该站点会生成一个访问令牌，应用程序可以使用该令牌在将来进行自身身份验证。优点：

• 访问令牌可以被撤销
• 第3方应用程序看不到用户的密码
• 可以授予访问令牌特定的权限（而基本身份验证平等对待每个消费者）。
• 如果第 3 方应用程序被证明不安全，服务提供商可以决定撤销为该特定应用程序生成的所有访问令牌。

Answer 4

在可嗅探的环境中通过 http 进行的基本身份验证就像没有身份验证一样，因为密码可以轻松逆转并重新使用。针对上面关于 ssl 上的信用卡“有点”更安全的尖锐评论，问题是在同一通道上一遍又一遍地使用基本身份验证。如果您泄露密码一次，您就会危及该通道上每笔交易的安全性，而不仅仅是单个数据属性的安全性。

如果您知道您将在网络会话中一遍又一遍地传递相同的信用卡号，我希望您除了依赖 SSL 之外还能想出一些其他控制措施，因为信用卡号很可能经常使用的东西最终会受到损害。

Answer 5

如果您使用

htpasswd

生成密码，请考虑切换到

htdigest

。

摘要式身份验证即使在未加密的连接上也是安全的，并且设置也同样容易。当然，当您使用 ssl 时，基本身份验证是可以的，但是当您可以轻松使用摘要身份验证时为什么要冒险呢？

Answer 6

我的5美分。

1. 当然（正如其他人指出的那样）如果您发送/接收任何敏感信息（包括用户/密码），您应该使用 SSL。 （请避免查询字符串，即使使用 SSL）。
2. 您绝不能在应用程序/浏览器中存储用户密码，而应该存储不记名令牌或 api 密钥。您允许用户输入密码，并且应该发送一次（不是每次请求时）。这样您就永远不会将该密码存储在会话/cookie 中。
3. 基本身份验证要求在每次请求时发送用户密码。所以这就是问题所在。

Answer 7

顾名思义，“基本身份验证”只是基本的安全机制。不要依赖它为您提供无忧的安全保障。

在其之上使用 SSL 确实使其更安全，但还有更好的机制。