我的身份验证系统安全吗？

Question

我想通过遵循良好实践来实现身份验证系统，我希望它尽可能简单且受保护（即不要实现某些魔术哈希功能或让人感到英雄的东西。）只是想使用已知的哈希，但不确定正确的使用方式。 我读了一些有关Lastpass（密码管理公司）如何管理身份验证的文章，我喜欢他们的想法。因此，我想基于此实现自己的身份验证。

基本上，我会从客户端的密码创建身份验证密钥（因此，密码永远不会作为计划文本发送到服务器）。 该验证密钥将发送到服务器，然后在服务器端也执行一些哈希操作，并将结果与​​数据库内部的结果进行比较。

在我的客户端：

auth_key = PBKDF2(SHA256, password+username, last_login_fe_salt, fe_rounds)

说明-哈希密码+用户名+ last_login_fe_salt文本fe_rounds次

last_login_fe_salt- >用户在文本字段中输入用户名后会随机发送给用户的盐-老实说，不确定此last_login_fe_salt对于加密对字典攻击的效果如何，但是至少两个使用相同密码的人会发送不同的哈希值在他们的网络上。 任何黑客都可以通过从服务器询问来获取此数据，我可以添加服务器端限制（req / s，是否有所不同，等等。让我知道您的想法），也可以添加验证码。 用户成功登录后，服务器将生成一个新的随机字符串并将其保存到数据库中。

*我没有看到salt Lastpass在其客户端哈希上使用哪种解释，它们使用的是需要salt参数的PBKDF2算法。

fe_rounds- >输入用户名时服务器给定的回合数-它对每个人都是固定的，并且可以由服务器配置，在我读到的有关Lastpass的文章中，他们也没有解释从何处接收客户端回合数...

所以现在我们将auth_key原样发送到服务器...

在我的服务器端

现在我们正在创建一个新的哈希值，以比较数据库中的哈希值。 为什么还要另一个哈希？ 如果我理解正确，我们将哈希绑定到服务器端数据，例如密码（只有用户知道）和服务器数据的组合。

db_auth=PBKDF2(SHA256, auth_key, user_be_salt, 100,000+user_configurable_rounds)

user_be_salt- >保存在db中的随机数，只有服务器和获取数据库的人知道，这在每次成功登录时都会更改。

user_configurable_rounds- >迭代次数，每个用户都可以选择迭代次数（如Lastpass），因此攻击者还需要猜测迭代次数还是迭代次数？

我很高兴听到您对此认证系统的看法，如果它错了，不如向我解释原因并告诉我Lastpass做什么，因为我不了解他们的整个认证流程。

Answer 1

从安全角度来看，您所做的大多数事情都是无用的。 Lastpass有不同寻常的安全要求-请勿将其视为最佳实践的来源。

如果客户端负责哈希，并且该哈希的所有参数都是固定的， 则哈希实际上将成为密码 。 攻击者不需要知道原始密码； 他们可以简单地将哈希传递给服务器。

一般而言，如果不通过网络发送密码（对于传统的密码身份验证协议），或者让服务器以明文形式存储密码（对于不太常用的协议，例如SRP ），就无法通过网络验证密码。 在这两者中，前者是可取的，因为可以使用SSL / TLS之类的协议来保护密码在传输过程中的安全，而SRP之类的协议则要求密码的明文才能运行。

在客户端或服务器端调整PBKDF循环计数是没有意义的。 设置固定的回合计数，使哈希变慢，但又不会太慢，以至于会给客户端或服务器造成不必要的负载。 （对于服务器端的散列来说，100,000轮可能是多余的。使用这些设置来验证密码大约需要半秒钟，因此每秒仅两个登录请求将占用服务器上100％的内核！）