这种对用户进行身份验证的机制是否安全？答案

【问题标题】：Is this mechanism to authenticate a user secure?这种对用户进行身份验证的机制是否安全？
【发布时间】：2015-05-22 09:06:34
【问题描述】：

我正在开发一个网站，以了解有关 Web 编程的更多信息，并作为一家初创公司推出。我遇到的第一个问题是如何实现一个安全的登录系统。目前我已经采取了一些步骤，比如转义密码，然后使用盐对其进行哈希处理。但我想知道以下机制是否安全，

我会让用户输入用户名，并会继续检查用户是否输入了他的用户名（当文本框失去焦点或提交用户名的按钮时，也为了防止用户名列表通过在系统上设置 cookie 来阻止用户，如果多个进行了错误的尝试，或者可能对每个错误都使用了验证码），一旦输入了用户名，就会将随机存储的盐发回给用户。
使用输入的盐和密码，用户将对密码进行哈希处理并以表单形式发送
我将通过比较哈希来验证密码

我认为这将是有益的，因为服务器端我不必做任何处理，因此我不必担心 DoS 攻击，因为我在某处读到使用像 BCrypt 这样的慢速哈希会暴露网站DoS 攻击。此外，用户的密码永远不会通过网络进行通信，从而防止有人嗅探网络。

请给我一些参考或任何可以帮助我安全实施的东西。考虑我是菜鸟，因为我仍然开始学习，想知道您对此有何看法，可能存在哪些缺陷？以及什么必须是安全的策略。

更新- 我得到了很多答案，通常都假设我认为这是 SSL 的替代方案；不，事实并非如此。防止嗅探是指保护，以防某些攻击者可能让用户使用 SSL 代理。 仅供参考 - https://security.stackexchange.com/questions/19616/why-is-it-possible-to-sniff-an-https-ssl-request

【问题讨论】：

是什么让您认为自己不会受到 DoS 攻击，仅仅因为您在客户端而不是服务器端对密码进行哈希处理？
为什么您认为用户不会简单地删除您用来阻止多次失败尝试的 cookie？
你不应该在浏览器中散列，这就是几年前phpbb遇到麻烦的原因，因为当你到达另一边时你必须对散列进行散列，而双重散列实际上可以使密码更可预测。无论如何，哈希密码相当于原始密码。
如果您只是学习 Web 开发并且想要生成一个实际工作的应用程序身份验证，而这很难正确执行，那么这不是一个好的开始。使用一个框架，如果你想学习研究优秀的 php 开源应用程序是如何做到的，但我敦促你不要尝试自己真正实现它。如果只是为了学习，可能但即使在那里，您如何从专家那里获得认真的代码审查？
指望没有人来打扰你，因为你没有使用框架，这忽略了一个事实，即来自你认识的人的威胁是特别危险的。如果您认为您不必重新对服务器端进行哈希处理，那么您就不明白任何人都可以查看您的数据库并知道要输入什么密码。 stackoverflow.com/questions/348109/…stackoverflow.com/questions/8611050/…owasp.org/index.php/How_to_write_insecure_code

标签： php security hash

【解决方案1】：

客户端散列可以有其优势，但你不能没有服务器端散列。在您的场景中，计算出的哈希值充当新密码。具有数据库读取权限（SQL 注入）的攻击者将看到此哈希，并可以直接将其用作登录密码。

使用带有成本因素的慢速散列是强制性的，通常是在服务器端完成，因为客户端语言速度较慢并且可以执行更少的轮次。当然，有人可以使用它来进行 DoS 攻击，但也可以对所有其他页面进行此操作。密码的大小无关紧要（因为偶尔可以读取），因为在第一轮之后，只有散列会被散列。

如果您打算进行客户端散列，请不要忘记在服务器上计算（快速）散列。而且您必须确保散列在客户端正确完成。更重要的是，您使用 SSL 发送凭据。

你可能对Secure authentication: partial client-side key stretching…这个问题感兴趣。

编辑：

我将尝试总结客户端哈希的要点。

具有盐和成本因子 (BCrypt/PBKDF2/SCrypt) 的 慢散列 算法是强制性的，这是唯一使从散列中检索原始密码变得困难的事情，如果密码很弱。可以在客户端执行此操作。
服务器端散列也是强制性的，以防止攻击者直接使用存储的散列作为密码，如果他知道的话。没有盐（SHA-256）的哈希可以很快，因为输入（BCrypt哈希）有足够的熵。这么强的 60 个字符的“密码”是无法成功破解的。
如果攻击者因为输入太强而无法破解快速 SHA-256 哈希，他可以尝试使用原始密码（来自字典）进行暴力破解。但要做到这一点，他必须首先计算慢速 BCrypt 哈希，然后计算快速 SHA-256 哈希。
像 JavaScript 这样的客户端语言通常是解释型的，并且比编译后的代码慢得多，因此您可以像在服务器上一样在同一时间内执行更少的轮次（这会削弱安全性）。如果你有可能在客户端运行原生代码，那么做慢哈希客户端没有任何缺点。

【讨论】：

"ManInTheMiddle 会看到这个哈希值，可以直接用它作为登录密码。" MIM 攻击还可以看到常规文本密码，这将是一个更大的问题。是的，您提到的一个很好的观点是，客户端语言速度较慢。但我认为这不会引起注意。但这将是服务器上的显着负载，因为服务器必须散列多个用户的密码。我想了解更多关于我为什么要在服务器上重新设置密码？。
对于最后一点，我假设哈希总是正确的，除非用户更改了他身边的一些脚本，这只会导致无法访问用户。是的，无论我是否在客户端散列，我都会使用 SSL。
不，因为 MIM 不知道盐。
@Dapu - 你是对的，MIM 攻击者也会看到纯文本密码，这就是你需要 SSL 的原因。我想到的是，如果有人能够从数据库（SQL 注入）中读取哈希值，他可以直接使用它们登录，这可以通过做另一个哈希服务器端来防止。服务器端哈希可以是无盐且快速的，因为输入的熵总是很高（BCrypt 哈希）。不幸的是，使用 JavaScript 计算哈希客户端明显慢，所以不是系统更慢，通常可用的解释语言是。
@Dapu - 我不确定你是否理解正确。完全完成哈希以保护密码，以防有人可以读取数据库中的哈希，可以阻止攻击者。在客户端（BCrypt）和散列服务器端（SHA-256）进行盐渍是为了防止不同的事情发生。我进行了更新以更清楚地解释它。或许你也对我的tutorial about safely storing passwords感兴趣。

【解决方案2】：

不，您不应该向用户发送任何“盐”。它可以被嗅探。

您所做的基本上是发送类似（csrf-）令牌之类的东西，可以使用一次。这没什么错，但你似乎在重新发明轮子。

【讨论】：

即使有人嗅到了盐，它对攻击者也没有用，因为每个用户的盐是不同的。同样对于受害者来说，攻击者将无法使用具有多种密码组合的盐，因为它会在 10 次尝试时被阻止。使其无用。
你显然不知道中间人攻击是什么。就像其他人说的那样：不，你的策略根本没有用。
我知道什么是中间人攻击，感谢您的回答。我认为与您进一步讨论这个问题不会产生任何建设性的结果。

【解决方案3】：

说真的，我认为您的解决方案只对黑客有用。如果我嗅探通信，我将逐渐获得用户名、盐和密码哈希。您必须通过网络发送所有这些值（获取盐的用户名，验证尝试的密码哈希）。现在我可以直接在恶意登录请求中使用嗅探密码哈希或在本地开始破解密码（用户通常使用相同的密码来获得更多服务）。因为我不需要发送请求来猜测密码，所以对身份验证尝试的所有检查和限制都已失效。取决于哈希算法，它或多或少会消耗时间。我认为网络嗅探是您计算不通过网络发送纯密码的主要目的。

您可以使用 TLS 保护您的网络通信，但是在客户端发送盐和散列密码的所有事情都是不必要的。您可以将纯文本密码发送到服务器。但是，是的，在客户端上散列密码，如果你愿意，为什么不呢。你可以使用即。如果您认为 bcrypt 是性能问题并且可能是 DOS 原因，则 sha1 也在服务器上。

用于通过不安全网络传输信息的协议的一个很好的例子是OAuth 1.0a，即使在其中，您也需要一些密码学或 TLS 来传输消费者机密。

如果我的理解有误，请告诉我。

【讨论】：

对于你的第一点“说真的，我认为你的解决方案只对黑客有用。如果我嗅探通信，我将逐渐获得用户名、盐和密码哈希。”，你不认为它甚至如果他们嗅探密码本身而不是散列，那就更成问题了？他们甚至不需要解决哈希。不，网络嗅探不是我想到这个解决方案的目的，我的主要目的是降低服务器端的复杂性并确保用户密码永远不会离开他的系统，即使在网络上也是如此。只是一个密码散列离开了他的系统。是的，我非常喜欢你关于使用 OAuth 的观点。我会学的
您受限于客户端浏览器中的加密。如果您使用快速哈希函数，这不是一个大障碍。因此密码永远不会离开客户端，但普通密码可以相对较快地破解。如果你只想在客户端创建哈希，你也必须在数据库中拥有这个哈希。
是的，你是对的，需要快速散列，这也只在低端设备上。你能详细说明它是如何被破解的吗？而且即使我在服务器端计算哈希，我也必须将哈希存储在数据库中。
低端设备是指处理器功率较小的移动设备
它可以通过暴力破解技术破解。没有每个用户都有十个字符长的密码，所有字符。我的意思是你不可能在数据库中使用比你从客户端获得的更强的哈希值。就是这样。

【解决方案4】：

我想我能看到的唯一缺点是在低端移动设备上使用它。

【讨论】：