我想通过遵循良好的做法来实现一个身份验证系统，我希望它尽可能简单和安全（我不会实现一些魔法哈希函数或者某些东西来感受英雄......）只是想使用已知的哈希但不确定使用它的正确方法。 我读了一些关于Lastpass（一家密码管理公司）如何管理他们的身份验证的文章，我喜欢他们的想法。所以我想基于它实现我自己的身份验证。
基本上我是从客户端的密码创建一个身份验证密钥（因此密码永远不会作为计划文本发送到服务器）。 发送到服务器的身份验证密钥，而不是服务器端的一些哈希操作，并将结果与数据库内的结果进行比较。
在我的客户端：
auth_key = PBKDF2(SHA256, password+username, last_login_fe_salt, fe_rounds)
解释 - 哈希密码+用户名+ last_login_fe_salt 文字 fe_rounds 次
last_login_fe_salt - ＆gt;一旦他/她在文本字段中输入用户名，就会向用户发送随机盐 - 说实话，不确定这个last_login_fe_salt对于字典攻击的加密是多么有效，但至少两个拥有相同密码的人会在他们的网络上发送不同的哈希值。 任何黑客都可以通过从服务器询问来获取这些数据，我可以添加服务器端限制（如果它有所不同等req / s ...让我知道你的想法）还添加验证码可能是一个好主意。当用户成功登录时，服务器会生成一个新的随机字符串并保存到数据库中。
*我没有看到Lastpass在其客户端散列中使用的任何解释，他们正在使用需要salt参数的PBKDF2算法。
fe_rounds - ＆gt;键入用户名时服务器给出的轮数 - 它是固定的每个人，可以由服务器配置，也在我读到的关于Lastpass的文章中，他们没有解释他们从哪里收到客户端轮数......
现在我们将auth_key原样发送到服务器......
在我的服务器端
现在我们正在创建一个新的哈希值来比较db中的哈希值。 为什么另有哈希？如果我理解正确，我们绑定服务器端数据的哈希值，如密码（只有用户知道）和服务器数据的组合。
db_auth=PBKDF2(SHA256, auth_key, user_be_salt, 100,000+user_configurable_rounds)
user_be_salt - ＆gt;保存在数据库中的随机数，只有服务器和获取数据库的人才知道，每次成功登录都会发生变化。
user_configurable_rounds - ＆gt;迭代次数，每个用户都可以选择迭代量（比如Lastpass），所以攻击者还需要猜测数量或迭代次数？
我很高兴听到你对这个身份验证系统有什么看法，如果它错了，请向我解释原因，并告诉我Lastpass做什么，因为我不了解他们的整个身份验证流程。
答案 0 :(得分：0)
从安全角度来看，您所做的大部分内容都是无用的。 Lastpass具有不同寻常的安全要求 - 不要将它们视为最佳实践的来源。
如果客户端负责散列，并且该散列的所有参数都已修复，则散列有效地成为密码。攻击者不需要知道原始密码;他们可以简单地pass the hash到服务器。
一般来说，如果没有通过网络发送密码（对于传统的密码身份验证协议），或者让服务器以明文形式存储密码（对于不太常用的协议，如{），则无法通过网络验证密码。 {3}}）。在这两者中，前者是可取的，因为可以使用诸如SSL / TLS之类的协议来保护传输中的密码，而像SRP 这样的协议需要密码的明文来操作。 / p>
在客户端或服务器端调整PBKDF轮次数是没有意义的。设置一个固定的循环计数，使哈希缓慢，但不会太慢，以至于它会在客户端或服务器上造成不适当的负载。 （服务器端哈希值可能超过100,000轮。使用这些设置验证密码大约需要半秒钟，因此每秒只有两次登录请求会使用服务器上一个核心的100％！）