我正在寻找一个建立的安全机制，除了服务器端密码哈希之外，还可以应用客户端密码哈希。客户端可以是web应用程序，也可以是移动应用程序。客户端和服务器之间使用HTTPS进行通信。服务器应该使用bcrypt或类似安全的密码散列算法。
现在，我不想将未加密的密码从客户端发送到服务器，以防止对用户的内部攻击。我想确保我们的管理员都无法获得原始密码，因为——我们都知道——大多数人在多个网站上重复使用他们的密码，或者使用密码方案来获得易于记住的密码。
此外，我想在身份验证协议中实现一个额外的两因素安全层，利用存储在客户端的秘密，以进一步加强整体安全性。
是否有任何已发布和经过验证的机制可以用于这种情况?
编辑在我的场景中，邪恶的管理员无法控制应用程序的代码。进行身份验证并提供敏感数据的服务器是REST服务器。应用程序代码由不同的服务器(对于web应用程序)或通过AppStore(对于移动应用程序)交付。我还在考虑这样的场景:攻击者对连接HTTPS服务器和应用服务器的内部网段只有只读访问。在大多数实际设置中，SSL终端是在专用服务器上完成的。
与网站相比，您的应用程序的场景非常适合客户端哈希。应用程序已经包含计算哈希值的代码，并且代码不能被拦截/更改，因为这将是JavaScript的情况。更重要的是，您可以将服务器从CPU密集型计算中解脱出来。
以下是注册的必要步骤:
- 在客户端，使用带成本因子的慢散列函数计算密码的散列。合适的算法是BCrypt, PBKDF2或SCrypt。大多数库都会自己生成一个随机盐，并将其包含在生成的哈希值中。
- 发送客户端哈希到服务器(您已经提到了SSL连接)。
- 在服务器端，再次计算发送的客户机哈希值的哈希值。这一次，您不需要盐，您可以使用像SHA-256这样的快速算法。这是安全的，因为客户端哈希已经是一个非常强的"密码"，不可能从服务器哈希中伪造客户端哈希。
- 从客户端哈希中提取盐分、成本因子、算法等参数。
- 在数据库中存储服务器哈希值和参数(salt，…)
登录的步骤如下:
- 客户端必须请求存储在服务器数据库中的参数(salt，…)
- 客户端使用与注册时相同的参数计算密码哈希值。
- 发送客户端哈希给服务器。
- 服务器再次使用快速算法对客户端哈希进行哈希，并将其与数据库中存储的哈希进行比较。
这比单独的服务器端散列要复杂一些，因为您必须单独存储参数(salt，…)。