在这种情况下，希望通过 http/s 对用户进行身份验证。
在注册过程中，服务器会生成一个 salt。这个盐被发送给用户。然后他继续通过 js 用盐对他的密码进行哈希处理并将其发送到服务器。在那里，哈希再次用相同的盐加盐，两次散列和加盐的密码被写入带有明文盐的数据库。
如果有人尝试进行身份验证，他会发送他的用户名，获取盐并对密码进行哈希处理。这将发送给再次对其进行哈希处理的服务器，如果保存的哈希值与此相同，则用户已通过身份验证。
我想知道由于最近的心脏出血错误，永远不要暴露真实密码会很好。但是我读过双重哈希会增加碰撞的风险。
我想象的方式是最安全的方式还是我做错了什么？
我想知道由于最近的心脏出血错误，永远不要暴露真实密码会很好。
我可以看到你来自哪里，但你一直没有想到这一点。如果您对密码客户端进行哈希处理并将哈希发送到服务器，那么这个哈希本质上就是用户的密码。如果攻击者要获得客户端发送到服务器的这个散列，无论是通过心脏出血、MITM 攻击还是其他方式，攻击者所要做的就是将这个散列密码发送到您的服务器（无需再次散列客户端显然）为了登录。在客户端散列它不会给你带来任何好处。
但我读过双重哈希会增加冲突的风险。
理论上是的。如果密码比生成的散列长，则保证输入的熵减少。即使输入比生成的散列短，熵也有可能有所减少。再次散列这个减少的熵数据会进一步减少熵（理论上）。在实践中，这根本不重要。
“在注册过程中，服务器会生成一个盐。这个盐被发送给用户。他——”我将不得不在那里阻止你。
原则上，客户端散列没有任何问题，只要您了解它不会增加系统的安全性。但是，散列/摘要确实意味着收到的密码总是具有非常特定的形式，无论用户选择的实际密码的形状如何，这意味着您（作为服务器所有者）理论上不知道用户的密码发送给你。
它不安全，因为你——以及任何监听的人——都可以获取散列密码并破解它（因为在这方面你与攻击者没有什么不同）。但是，它确实增加了一层信任：“我必须竭尽全力找出您的密码是什么”。
考虑到这一点，在客户端加盐是没有用的，如果你从服务器获取盐，是一种错误的安全感：如果你将盐从服务器发送到客户端，任何可以看到用户的密码客户端也可以看到盐客户端。您不妨将加盐值写为<h1>页面上的标题，那里没有安全性，您只会浪费处理器时间加盐。
现在，您仍然希望使用盐在服务器上正确散列，但是让客户端进行任何加盐是没有意义的。只需给他们一个客户端消化器/哈希器（如 SHA256 库）并保留它。然后在服务器上，您收到密码，根据您所知道的散列密码应该是什么样子（正确的长度？在散列空间之外没有字符？等等）验证它，然后您使用自己的盐对输入进行散列并存储 /使用它来验证您的用户数据库。