用户输入密码并提交登录表单。密码被发送到服务器，运行身份验证，散列后的密码与数据库中存储的密码匹配。
这就是我所想的发挥作用的地方。我想知道的是，这种情况是否有用：
然后使用新的随机salt对用户的密码进行重新散列，并覆盖存储在数据库中的原始散列。下次用户登录时，他们仍然输入完全相同的密码，但正在检查不同的哈希。
请让我知道这是否是一种更安全的密码哈希方法。
编辑
我把这个问题写得很糟糕。。。。我一直在研究让非SSL登录脚本更安全的方法，并想出了一个主意，在通过后数据发送密码之前使用javascript对密码进行哈希。这让我觉得是一个半体面的想法，只是如果黑客拦截了散列后的帖子数据，那将毫无意义，因为从那时起，他可以使用散列发送虚假的帖子数据。我开始考虑每次都用新的salt重新散列pass，这样黑客每次想要访问该用户的帐户时都必须不断地重新嗅探连接。
这样，如果受害者的计算机上没有密钥记录器或某种客户端软件，黑客将无法访问客户端的密码，因此一次只能访问一个会话，一旦用户登录，哈希就会改变。当用户再次登录以获取新的哈希时，黑客将不得不监听。
我在这里看到的唯一区别是数据库中的salted散列会定期更改。
因此，每个设法读取数据库的攻击者都会有另一组哈希。但是，当其中一个散列被破坏时（例如，你找到了一个密码，该密码与salt一起给出了给定的散列），它很可能是原始密码，即使数据库中的salt和散列稍后发生变化，它也会继续工作。
所以，这里的安全没有变化。
我不确定这是否会使它更安全。如果黑客试图强行用户登录，那么数据库中存储的MD5/SHA1或任何内容都无关紧要。重要的是每次身份验证尝试需要多长时间，以及您的密码是否经过加密。您仍然需要将新的"随机"salt存储在数据库中，或者让它从数据库中的字段中派生出一些方法。确保使用按键拉伸（强化），并且每次登录尝试需要1或2秒就足够了。很明显，防止黑客访问机器或转储加密密码（通过SQL注入、服务器漏洞利用等）。