我使用安全的单向哈希来在服务器上存储密码。我可以将相同的哈希发送到客户端以用作令牌。
它应该是一个牢不可破的单向哈希（SHA-256或类似的），而且现在可以告诉它它来自用户密码，或者甚至知道它在那里，除非你四处寻找。
寻找验证，如果这是O.K. ？
答案 0 :(得分：0)
如果它真的是一种方式，那么我假设你的服务器使用哈希而不是明文来验证登录。因此，发送密码哈希实际上与将密钥发送到您家的内门相同。还有一扇外门，但为什么要发送超过你需要/风险的东西。
您应该强烈考虑使用OpenID Connect来保护应用程序。 https://www.scottbrady91.com/OpenID-Connect/OpenID-Connect-Flows
OpenID Connect促进了Web应用程序的时间限制授权代码。如果你很好奇为什么所有的间接和层，这个SO答案是有价值的： What is the difference between the 2 workflows? When to use Authorization Code flow?
总之，这不是一个坏主意。
答案 1 :(得分：0)
没有。问题的严重程度取决于系统的其他细节，但无论如何这都是一个坏主意。
如果它是盐渍哈希，正确实现（哈希值之前的盐，每个用户使用独特的随机盐），那么单独的哈希就不会公开密码。但是，密码很少更改，因此密码的哈希很少会改变，因此截获此哈希的任何人都可以使用它来无限期地模拟用户。
如果这个哈希没有被腌制，问题会变得更糟。拦截这样一个哈希的坏演员很有可能从中破解实际密码。无论技术上不可逆的散列算法如何，都有大量常见密码及其散列的数据库，并且对于许多用户来说，破解未加盐的散列只是数据库查找的一个简单问题。如果用户碰巧在许多网站上使用此密码，这很常见，这可能会变成全面的身份盗用。
您的想法的一部分是使用令牌进行身份验证。该令牌应该是纯粹随机的并且严格限时，但每次用户登录时都会生成一个新令牌。
答案 2 :(得分：0)
道格拉斯指出，由于各种原因，这是不可能的。此外，如果您的用户发现这一点，您将极大地失去对您和您的产品的信任，并且可能会合法地伤害您，我非常确定这不是一个理想的选择:)。
我建议生成一个单独的令牌，它可能会随着时间的推移而过期，而是发送它们。
此外，它实施起来相当简单，因此谨慎无害。