基本访问身份验证是否安全？答案

【问题标题】：Is basic access authentication secure?基本访问身份验证是否安全？
【发布时间】：2010-07-24 00:17:43
【问题描述】：

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

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

【问题讨论】：

另见：Is BASIC-Auth secure if done over HTTPS?

标签： http basic-authentication

【解决方案1】：

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

【讨论】：

另一个区别：对于每个请求，密码都是重复发送的。（更大的攻击窗口）见security.stackexchange.com/a/990/95555
所以它是否安全？ :-D
@BGBruno 我的 2 美分：如果你不使用 SSL，它是不安全的。如果您使用 SSL，它将取决于您的应用程序。恕我直言，一次性 REST 请求很好，只要有其他服务器端安全措施（例如，避免 DoS 或暴力攻击）。但是，对于更复杂的身份验证场景，您最好使用更详细的东西。例如，您绝对不应该将其用作您的网站登录。
thx @lotif - 我研究这个主题很长时间，现在我使用#jwt+xcsrf

【解决方案2】：

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

正如@Nateowami 所述，security stack exchange thread 概述了基本身份验证的一些问题。

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

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

【讨论】：

这不适用于大多数身份验证机制吗？例如基于令牌的身份验证。服务器必须在每个请求中检查令牌的签名，这通常是 RSA 和 SHA2 的混合或仅 SHA2 ...

【解决方案3】：

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

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

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

【讨论】：

我同意除授予特定权限之外的所有要点，没有什么能阻止第三个应用程序看到在基本身份验证中使用的用户，并在此范围内向该用户/密码组合授予特定权限。
此外，您通常可以通过发回 401 响应代码并要求用户重新进行身份验证来“撤销”基本身份验证...

【解决方案4】：

在可被嗅探的环境中通过 http 进行基本身份验证就像没有身份验证一样，因为密码可以很容易地反转然后重新使用。为了回应上面关于通过 ssl 的信用卡“有点”更安全的尖刻评论，问题是基本身份验证在同一通道上一遍又一遍地使用。如果您泄露了一次密码，就会损害该通道上每笔交易的安全性，而不仅仅是单个数据属性。

如果您知道您将在网络会话中一遍又一遍地传递相同的信用卡号，我希望您能想出一些其他的控制措施，而不仅仅是依靠 SSL，因为这很可能是一种信用经常使用的卡号会被泄露……最终。

【讨论】：

无论您使用多少次，SSL 都是安全的。重复使用它不会增加信息泄露的机会
所有这些 cmets 的问题是基本身份验证本身没有安全属性。假设攻击者位于 SSL 终止之后，并且争论消失了。过期的会话令牌可以被盗，但只能在 x 时间段内有效。基本身份验证有一个令牌，一旦知道就一直有效，因此必须手动轮换，频率与过期令牌一样频繁，才能具有相同的安全属性。

【解决方案5】：

如果您使用htpasswd 生成密码，请考虑切换到htdigest。

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

【讨论】：

如果它是加密的，那么没有理由使用摘要而不是基本身份验证，就没有“机会”。如果连接未加密，则摘要式身份验证将防止泄露用户密码并防止重放攻击，但数据将以纯文本形式发送，我几乎不会称之为“即使在未加密的连接上也是安全的”。
“机会”更像是配置错误的服务器，允许某人访问未加密的页面或用户意外访问。这不是关于信息是通过 ssl 还是明文发送更好的问题。就密码认证安全标准而言，基本认证是最低的。你在野外看不到它是有原因的。
我想知道一般来说什么更好。 Basic 可以在 Web 服务器级别，与让 Jenkins 处理身份验证（它可以打开这么多 URL、帖子等访问和可能的错误）相比，它非常低并且减少了很多区域。那么对于这种情况有什么更好的方法（仅在 https 之外）。
“即使在未加密的连接上，摘要式身份验证也是安全的”——错误。人们可以在不知道密码的情况下简单地通过哈希来窃取身份。此外，通过查表（甚至可以使用 Google 完成）、彩虹表或低成本 GPU 暴力破解，很容易反转大多数密码哈希。

【解决方案6】：

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

在它之上使用 SSL 确实使它更安全一些，但有更好的机制。

【讨论】：

那么通过 SSL 发送信用卡详细信息比纯文本“更安全”吗？
@Chris Diver - 你是什么意思？
基本身份验证凭据是“基于 SSL 的明文”，就像通过 HTTP POST 发送您的信用卡号是“基于 SSL 的明文”一样。因此，通过 SSL（这些天是 TLS）来实现它在传输过程中是安全的。