Web 是否也应将重新键入的密码发送到服务器？

注册帐户或重置web服务的密码时，用户通常需要键入两次密码，以确保不会意外拼错密码

如果意外拼写错误是此功能的唯一考虑因素，那么可以接受（从网站设计的角度来看，甚至更好）由浏览器/客户端JavaScript验证重新键入的密码，而不是将其发送到服务器进行验证

---

这项功能的唯一考虑因素是意外拼写错误，我说得对吗？

这有点迂腐，但确认字段用于意外拼写错误，而不是密码性质的拼写错误

回答你的问题；是的，密码重新输入字段仅用于验证用户的输入

JavaScript可用于确保条目符合密码要求（长度、特殊/有效字符、强度等），但如果用户禁用了JavaScript怎么办？在这种情况下，您必须为要在服务器端验证的密码编写代码。此外，由于代码是客户端的，因此可能会被篡改以绕过您的检查（有些人只是喜欢破坏东西）。最重要的是，从web设计的角度来看，客户端需要下载更多的代码来实现这一点，而不是发布一个额外的表单字段，因此在考虑移动应用时会有额外（尽管非常小）的数据使用开销

然而，所有这些都可能变得不必要。如果您的密码重置过程足够安全和可靠（例如，需要电子邮件地址验证），那么您可以说不需要用户验证他们是否输入了他们想要的内容。您需要一个过程来删除未经验证的帐户，以防他们输入错误的电子邮件地址。。。除非您让他们输入两次电子邮件地址；）例如，基于堆栈溢出只需要我在注册时输入一次密码这一事实，这似乎是该网站使用的方法

---

希望这能有所帮助。

是的，我觉得这听起来不错。只需立即对这两个哈希值进行哈希，比较哈希值，然后如果它们匹配，则通过https将一个哈希值发送到您的服务器。@Jameson为什么要在发送到服务器之前对密码进行哈希？这将使哈希逻辑上成为用户的密码——拦截哈希的人可以模拟用户。现在我通过HTTPS发送真正的密码，然后在服务器上进行salt和hash运算，然后再将其存储到数据库中。我不认为比较hash而不是值有什么意义，也不认为仅仅为了这个目的而将hash运算引入JS。是的，这只是用户的便利…@Bernard人们喜欢做kirchoff会嘲笑的额外的事情，但在人类层面上，这让他们感觉更好。。。如果https有效，那么为什么要散列呢？如果https不起作用，哈希仍然无法保护密码。