java - 这种处理客户端/服务器哈希密码的技术是否正常？

Question

阅读很多关于如何以正确的方式处理HASH SALT +密码的方法 我想出了这个。您如何看待这种情况：

新用户首次注册时。

• 客户端在本地输入名称/传递，并使用公钥RSA加密发送到服务器。
• 服务器验证用户/通过，如果决定被授予，则发回HASH SALT +通行证版本。
• 私有SALT存储在服务器上。

现在，当用户连续记录时，他使用上述客户端存储的SALTED密码，如果黑客需要密码，他需要攻击服务器以获取SALT吗？使用此HASH SALT +密码进行的所有连续日志记录也是公共密钥RSA加密的。

我不是加密专家，但知道可以使用两种方式公钥/私钥加密和其他更高级的方法。这有点高于我的头，这就是我问这个的原因

这个逻辑有什么不对？

Answer 1

没有必要将salt保密，因为它将使用用户名和密码进行哈希处理，以便创建唯一的（基于会话的）哈希。鉴于它是一个散列，它无法逆转（即你无法从散列中获取用户名，密码或盐）。所需要的只是生成会话盐并将其与服务器上的任何其他会话变量一起保存。然后，服务器将使用用户名，密码和salt重现哈希值，并将其与客户端发送的值进行比较。

这样你根本不需要加密（尽管建议使用）。如果您没有安全的网站（即使用https），那么您仍然可以使用此技术来保护密码。

此技术称为HMAC。

Answer 2

这个怎么样？

第一次登录所有客户的情况如何，
首先通过创建应用于密码的随机大SALT来本地隐藏平面站点密码 （现在可见的密码在本地出现了）

然后他们使用公钥RSA加密登录到服务器 创建一个新的用户帐户，服务器保存上面本地创建的哈希密码。

下次同一用户使用公共登录时 密钥RSA加密服务器将比较哈希

对于黑客登录，他需要使用公钥RSA加密加密的哈希密码

任何评论？

<强>更新 这有一个问题。
  - 如果SALT是随机的，现在有比较密码的方法，如果让我们说用户卸载然后重新安装程序并想要使用他的旧帐户再次登录。
他的旧帐户SALT +密码将不一样。所以我们需要向USER发送一个SALT 或以非常聪明的方式在本地创建盐，以便黑客看不到这一点。

ATE：