你提出了几个问题。

服务器信任

一旦发送密码，您永远不知道服务器将如何处理您的密码

密码重用

您可以防止密码重复使用：不要在多个地方使用相同的密码。

散列

如果您在将密码发送到服务器之前对其进行哈希处理，则哈希密码将成为密码。如果服务器会存储它，并且它会被攻击者读取，他就可以使用它登录。他不需要原始密码，因为服务器会检查哈希。它将防止在不同网站上使用密码，但最好的措施是不要重复使用密码。

在这种情况下工作的协议是挑战-响应方案。服务器可以向客户端发送质询，客户端可以使用密钥哈希协议（如 HMAC+SHA1）对质询进行哈希处理并将其发送回服务器。然而，服务器仍然需要密码来验证哈希，因此必须存储它。

如果您想要在客户端和服务器之间没有共享秘密的方案，请查看非对称加密。你可以给服务器你的公钥，并让它通过用私钥加密一个随机数来验证你是谁。为此，您可以使用 SSL 和客户端证书。

除非服务提供商让您查看数据库，否则无法保证。这在过去已被证明是一种风险，毫无疑问还会再次发生。

在这种情况下，在服务器对您的密码进行预散列之前，您不能做太多事情，因为这基本上使您的预散列密码成为您的密码在未进行预散列的环境中的目标。您对服务器端/客户端问题的链接很好地回答了这个问题。

相反，减少对技术解决方案的关注，而更多地关注合同解决方案 - 要求您的提供商对密码进行哈希处理，并包括处罚条款。审计权是一项有用的要求。

我认为没有一种实用的方法可以测试服务器以知道它只存储密码的哈希值，但我可以想到一个理论上的方法：

给定常见散列算法（MD5、SHA1）的已知散列冲突，如果服务器使用散列冲突中的任何一个对您进行身份验证，您可以测试服务器以存储散列密码。

示例：假设“abc”和“xyz”都具有 MD5 哈希值 0123456789ABCDEF（显然这不是真的）。如果您可以使用“abc”和“xyz”作为密码登录，则可以验证服务器是否使用 MD5 哈希。

但这在实践中是无用的，原因如下：

• 如果服务器正确地加盐它的哈希值（即 hash("abc") = hash("xyz") 但是 hash("abc" + salt) != hash("xyz" + salt)
• AFAIK 没有已知的 SHA1 哈希冲突，这是常用的。
• 对于符合常见密码限制的值（例如密码只能有数字和字母并且有最大长度），获得哈希冲突会更加困难
• 即使服务器存储了您的密码哈希以进行身份​​验证，它也不能确认服务器也没有将您的密码以明文形式存储在其他地方（我已经看到密码出现在系统和 Web 日志文件、数据库复制日志中，会话数据文件等）。

在实践中，您应该假设网站做错了，因此您不应该为不同的网站使用相同的密码。

你不能。服务器可以对您发送给它的数据做任何它想做的事情。即使它声明数据是安全的，你也无法判断这是否真的是真的。因此，您要么信任它正确处理您的密码的服务器。或者您自己安排并为每个站点使用不同的密码。

充其量这些密码也彼此完全不同，因此无法从一个推断到另一个（即没有明显的前缀/后缀）。您可以使用密码管理器来生成和记住这些密码。由于其中许多都嵌入到浏览器中，它们还有助于防止网络钓鱼，因为存储的密码与某些站点/URL 相关联。

您是否为不同的网站使用不同的密码和/或密码管理器来生成/记住这些密码取决于您自己的风险感知。

我个人使用密码管理器，因此每个站点都有不同的密码。明显的缺点是没有它我只能登录几个站点，例如。G。当我不在我的机器上时。但由于其中之一也是 OpenID 提供商，我很高兴也能够登录 Stack Exchange 网络。