这种哈希验证安全吗？
我要问的问题只是因为我很好奇。我认为我正在做正确的事情，但我想确保它实际上是正确的事情。这是关于哈希的。
我当前正在构建的网站具有多个 Ajax 组件。首先，未登录的用户无法使用这些组件。其次，登录的用户只能以自己的名义执行请求。它很容易伪造，因为我发送了用户 ID。
我的验证方法如下。每个用户在数据库中都有一个包含随机信息的列，例如 8 个字符的随机字符串。除了用户发出的每个 Ajax 请求之外，该随机字符串也会作为哈希字符串发送。当服务器收到 Ajax 请求时，该哈希值会与用户表进行匹配，以确保 ID 和哈希值是有效的一对。如果是，则该请求有效。
“秘密”随机字符串永远不会进入用户领域，并且不容易被猜测，这意味着用户永远无法生成哈希值。这种保护请求安全吗？有什么缺点吗？如果我加点盐会更好吗？
顺便说一句，这种验证真的让我很感兴趣。我学习了交互设计课程。 “我们”的原则是“世界上的知识和头脑中的知识”。散列确实使用该技术将元数据从“头部”传输到“世界”（反之亦然）。头部和世界都有自己的比较和解密元数据的方法，因此不可能冒充请求。只要世界不知道头脑所知道的事情。
嗯，也就是说，我想知道我的请求是否（相对）安全。提前致谢！
雷德尔
The question I'm about to ask is just because I'm curious. I think I'm doing the right thing, but I want to make sure it actually is the right thing. It's about hashing.
The website I am currently building features several Ajax-ed components. First of all, users that are not logged in cannot use these components. Second, users that are logged in can only do their requests in their own name. It's pretty easy to forge, because I send User-id's.
My verification method is as follows. Each user has a column in the database that holds random information, like a 8-character random string. Alongside every Ajax request a user makes, this random string is sent as a hashed string. When the Ajax request is received by the server, this hash is matched with the user table to make sure the ID and hash are a valid couple. If so, the request is valid.
The 'secret' random string never enters the user realm and is not easy to be guessed, which means that the hash can never be generated by the user. Is this kind of securing a request safe? Are there any drawbacks? And would it be better if I would use some salt?
On a side note, this kind of verification really interests me. I followed a course in interaction design. 'We' have the principle of 'knowledge in the world and knowledge in the head'. Hashing really uses that technique to transfer meta-data from the 'head' to the 'world' (and vice versa). Both the head and the world have their methods of comparing and decrypting the meta-data, thus making it impossible to impersonate a request. As long as the world doesn't know what the head knows.
Well, that said, I'd like to know whether my requests are (relatively) safe. Thanks in advance!
Reinder
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，但有一些注意事项。
1) 如果哈希值以明文形式发送，则可能会受到欺骗。拦截哈希值的攻击者现在可以冒充有效用户。为了真正的安全，您需要保护通道 (HTTPS)。
2) 确保使用现有的加密安全哈希。不要尝试自己推出。我建议远离 MD5。鉴于这是一个未开发的情况并且 SHA1 实现已经存在，所以没有理由使用 MD5。
Yes subject to a couple caveats.
1) If the hash is sent in the clear it is subject to spoofing. An attacker who intercepts the hash can now impersonate the valid user. For true security you would need to secure the channel (HTTPS).
2) Make sure you use an existing cryptographically secure hash. Don't try to roll your own. I would recommend staying away from MD5. Given this is a greenfield situation and SHA1 implementations exists there is little reason to use MD5.
据我所知，是的，只需确保使用与其密码相关的内容对其进行加密（以便您可以解密它，例如密码的前 2 个和后 2 个字母），添加签名，使用 HTTPS（可以是如果您使用的服务器没有充分加密，即使您的网站连接已充分加密，则可以绕过），如果您找到理由，请添加盐，并确保不要使用 MD5（我推荐 sha256、sha512 或 Whirlpool）。
For all I know, yes, just make sure to encrypt it with something related to their password (so you can decrypt it, eg. the first 2 and last 2 letters of their password), add a signature, use HTTPS (it can be bypassed if the server you are using is not adequately encrypted even though you're website's connection is), add salt if you find a reason to, and make sure NOT to use MD5 (I reccomend sha256, sha512, or whirlpool).