了解跨域用户认证
目标：Website1 通过 http 请求发送 Website2 用户数据。
问题：Website2 确保数据来自Website1，而不是某个黑客。
注意：我不会使用 HTTPS，我意识到这会解决一个大问题，但目前 GAE 不支持您自己的域名的 SSL：http://code.google.com/appengine/kb/general.html#httpsapps
所以我通过加密和发送取得了一些巨大的进步两个站点之间的数据，另一个站点能够解密并读取数据。我在 Google App Engine/Python/Django-nonreal 上，此页面是让 pycrypto 工作的绝佳资源： http://code.activestate.com/recipes/576980/ Kn
所以我很高兴知道用户数据已加密并且您需要拥有密钥才能读取它，但是 Website2 怎么可能知道该请求来自 Website1？是什么阻止黑客再次发送完全相同的请求，并且 Website2 认为该黑客可以在 Website2 上执行操作？
例如，难道有人不能监听 http 请求并记录通过线路发送的加密数据吗？然后黑客可以使用 Website1 之前使用的相同值执行自己的请求，并且黑客可以对 Website2 执行与 Website1 相同的操作？本质上，黑客会告诉 Website2 他们是 Website1 的有效登录用户。
总体目标：向 Website2 告知仅来自 Website1 请求的用户数据。黑客使用与 Website1 发送到 Website2 相同的加密数据发出的任何其他请求都不会起作用，除非您的 Website1.
不确定我的解释是否足够好，或者我是否没有一个非常基本的理解，但感谢您的帮助。
Goal: Website1 sends Website2 user data through http requests.
Problem: Website2 is ensured that the data came from Website1, and not some hacker.
NOTE: I will not be using HTTPS, I realize that'd solve a big problem, but right now GAE doesn't support SSL for your own domain name: http://code.google.com/appengine/kb/general.html#httpsapps
So I've made some great progress by encrypting and sending data between two sites, and the other is site able to decrypt and read the data. I'm on Google App Engine/Python/Django-nonreal, and this page was a great resource for getting pycrypto to work: http://code.activestate.com/recipes/576980/ Kn
So I'm comfortable with knowing user data is encrypted and that you need to have the key to read it, but how could Website2 KNOW that the request came from Website1? What's stopping a hacker from sending the exact same request again, and Website2 thinking this hacker is valid to do stuff on Website2?
For example, couldn't someone just listen in on the http request and record what the encrypted data was send across the line? And then the hacker could do their own request, with the same values that Website1 used before, and the hacker could do the same things to Website2 that Website1 could? Essentially the hacker would be telling Website2 that they are a valid signed-in user of Website1.
Overall Goal: Website2 is told user data which only comes from requests from Website1. Any other requests from a hacker that uses the same encrypted data Website1 sent to Website2 won't work unless your Website1.
Not sure if I explained well enough, or if its a pretty basic understanding that I just don't have, but thank you for your help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
为了防止重放攻击，您需要包含随机数和 MAC（消息身份验证代码）。
MAC 可以简单地是加密消息内容的 HMAC-SHA1。接收方将计算相同的 MAC 并确保其匹配。 HMAC-SHA1 的密钥必须是双方都知道的秘密。此步骤很重要 - 仅仅因为您的数据已加密并不意味着它不能被篡改。特别是，如果攻击者只能改变随机数（见下文），那么您就会遇到问题。所以使用合适的MAC。
随机数应位于消息的加密部分内，并且仅使用一次。。接收端应记录随机数并拒绝任何具有相同随机数的未来消息。这是防止重放攻击的关键。
您还可以通过为随机数附加一个到期日期来避免保留无限数量的随机数。过期日期后收到的消息应被拒绝。可以在过期日期以及考虑到可能的时钟差异的几个小时后从可见随机数数据库中删除随机数。
正确生成随机数可能很棘手。这是一种技术：
您可以在超过最大预期时钟漂移量的时间段后删除虚拟数据存储实体。几个小时应该足够了。
In order to prevent replay attacks, you'll need to include a nonce and MAC (Message Authentication Code).
The MAC can simply be a HMAC-SHA1 of the encrypted message contents. The receiving side will compute the same MAC and make sure it matches. The key for the HMAC-SHA1 must be a secret known to both sides. This step is important - just because your data is encrypted doesn't mean it can't be tampered with. In particular, if the attacker can alter just the nonce (see next), you'll have problems. So use a proper MAC.
The nonce should be within the encrypted portion of the message, and used only once ever. The receiving end should record the nonce and reject any future messages with the same nonce. This is the key to preventing replay attacks.
You can avoid having to keep an infinite amount of nonces by also attaching an expiration date to the nonce. Messages received after the expiration date should be rejected. Nonces can be deleted from the seen-nonce database after the expiration date, plus a few hours to account for possible clock differences, passes.
Generating the nonce can be tricky to do properly. Here's one technique:
You may delete the dummy datastore entity after a period longer than the greatest amount of expected clock drift passes. A few hours should be plenty.
有多种方法可以做到这一点：
使用随机数
验证
握手
等等。
但是如果这是为了身份验证，为什么不这样做呢？你用OpenID吗？这已经解决了所有这些问题，并且几乎所有平台/框架都有现成的库。
There are multiple ways of doing this:
Using nonces
Verification
Handshake
and many more..
But if this is for authentication, why don't you use OpenID? This has solved all these problems and there are ready libraries for pretty much all platforms/frameworks.