在重定向用户的同时将登录密钥从一个网站传输到另一个网站的简单而安全的方法是什么？
我想创建一个用于登录、新闻和用户管理的门户网站。以及门户登录后重定向到的另一个 Web 应用程序网站。
我的目标之一是能够在不同的服务器上托管门户和网络应用程序。一旦用户成功登录并重定向到 Web 应用程序，门户就会将用户的 ID 传输到 Web 应用程序。但我不希望人们能够通过将用户 ID 直接传输到 Web 应用程序来绕过登录或访问其他用户帐户。
我的第一个想法是将加密的用户 ID 作为后变量或查询字符串值进行传输。使用某种公钥/私钥方案，并向密钥添加日期时间戳以使其每次都不同。
但我以前没有做过这样的事情，所以我想知道是否有更好的方法来做到这一点。
（我可以通过数据库进行通信，让门户将用户 ID 与数据库中的密钥一起存储，并将该密钥传递给 Web 应用程序，该应用程序使用它从该数据库获取用户 ID。但这似乎很疯狂。）
任何人都可以吗 ？给出一种方法或建议吗？或者这是一个坏主意？
感谢您抽出时间。
I want to create a portal website for log-in, news and user management. And another web site for a web app that the portal redirects to after login.
One of my goals is to be able to host the portal and web-app on different servers. The portal would transmit the user's id to the web-app, once the user had successfully logged in and been redirected to the web app. But I don't want people to be able to just bypass the login, or access other users accounts, by transmitting user ids straight to the web app.
My first thought is to transmit the user id encrypted as a post variable or query string value. Using some kind of public/private key scenario, and adding a DateTime stamp to key to make it vary everytime.
But I haven't done this kind of thing before, so I'm wondering if there aren't better ways to do this.
(I could potentially communicate via database, by having the portal store the user id with a key in a database and passing that key to the web app which uses it to get the user id from that database. But that seems crazy.)
Can anyone give a way to do this or advice? Or is this a bad idea all-together?
Thanks for your time.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
基本上，您需要的是单点登录解决方案。您所描述的内容听起来很像 SAML，尽管 SAML 更高级一点；-)
Basically, you are asking for a single-sign-on solution. What you describe sounds a lot like SAML, although SAML is a bit more advanced ;-)
这取决于您希望整个事情有多安全。生成带有嵌入时间戳的加密令牌仍然会让您容易受到欺骗 - 如果有人窃取令牌（即通过网络嗅探），他将能够使用窃取的令牌提交自己的请求。根据您的生存时间，您给予令牌的时间可能会受到限制，但坚定的黑客将能够做到这一点。此外，你无法腾出时间过小生活——你将拒绝有效的请求。
另一种方法是生成“使用一次”令牌。就欺骗而言，这是“防弹”的，但它需要服务器场内为您的应用程序提供服务的所有服务器之间进行协调，这样，如果其中一个服务器处理了令牌，其他服务器就会拒绝它。
为了使其在故障转移场景等方面真正安全，需要一些额外的步骤，因此这一切都归结为您需要它的安全程度以及您希望在构建它时投资多少
It depends on how secure you want this entire thing to be. Generating an encrypted token with embedded timestamp still leaves you open to spoofing - if somebody steals the token (i.e. through a network sniffing) he will be able to submit his own request with the stolen token. Depending on the time to live you will give your token this time can be limited, but a determined hacker will be able to do this. Besides you cannot make time to live to small - you will be rejecting valid requests.
Another approach is to generate "use once" tokens. This is 'bullet proof' in terms of spoofing, but it requires coordination among all the servers within the server farm servicing your app, so that if one of them processed the token the other ones would reject it.
To make it really secure for the failover scenarios, etc. it would require some additional steps, so it all boils down to how secure you need it to be and how much you want to invest in building it up
我建议查看 SAML
I suggest looking at SAML
PGP 可以工作，但在高流量站点上可能会变慢
我过去做过的一件事是使用共享秘密方法。只有我自己和其他网站运营商知道的一些令牌与标识用户的内容（例如他们的用户名）连接起来，然后使用校验和算法（例如 SHA256）对其进行哈希处理（您可以使用 MD5 或 SHA1，它们通常更可用，但它们的效率更高）更容易断裂）
另一端应该做与上面相同的事情。获取传递的识别信息并对其进行校验和。将其与通过的校验和进行比较，如果匹配则登录有效。
为了增加安全性，您还可以连接日期或其他一些轮换密钥。也有助于在双方运行 SSL。
PGP would work but it might get slow on a high-traffic site
One thing I've done in the past is used a shared secret method. Some token that only myself and the other website operator knows concatenated to something identifying the user (like their user name), then hash that with a checksum algorithm such as SHA256 (you can use MD5 or SHA1 which usually are more available but they are much easier to break)
The other end should do the same thing as above. Take the passed identifying information and checksum it. Compare that to the passed checksum, if they match the login is valid.
For added security you could also concat the date or some other rotating key. Helps to run SSL on both sides as well.
一般来说，答案就在
SHA256 / MD5 / SHA1中的某个地方，加上基于人类实际上必须思考的共享秘密。如果某个地方有钱，我们可以假设某些人会做的事情没有限制 - 我在高中时与[一个人]一起跑步了几个月，以观察这些人在实践中会做什么。几个月后，我学会了不要和那些人一起跑步。乏味地逃避工作，突然在周六凌晨 4 点，努力程度和分析功能只能被描述为“专业知识”（注意大写）必须有一个解决方案，其他网站如 Google，而这个解决方案不会有机会闪电中的蒲公英。在密码学的数学著作中有一项研究，通过该研究，一个机构（具有信誉良好的目标）可以发行信息 - 数字现金 - 可以存在于明线上，但不会泄露任何信息。谁会打破它们？我与[人]的经历
表明这是一项社会化研究，取决于你想和谁一起跑步。如果仅使用浏览器就可以更轻松地获取代码，那么如何防御嗅探器？
vis a vis
那么哪一个对攻击有价值呢？两者都不是，如果有人想从你那里抢走一些蛇油，也许你会接到凌晨 2:59 的电话，开头是：“我是一名投资者，我们在你的网站上投入了数千人。我刚刚接到我们安全专家的电话。” ....” 为这一时刻做好准备，您所能做的就是使用 SHA 等已建立的已知工具（其中 256 品种是公认的“下一个目标”）并进行跟踪控制，以便安全专业人员可以进行保险和粘合。
更不用说试图找到一个知道这些工具如何工作的人了，他们的第一道防线不是与你交谈......然后他们有自己的文献 - 他们会希望你使用他们的工具。
那么你就无法编写任何代码。
In general, the answer resides somewhere in
SHA256 / MD5 / SHA1plus shared secret based on human actually has to think. If there is money somewhere, we may assume there are no limits to what some persons will do - I ran with [ a person ] in High School for a few months to observe what those ilks will do in practice. After a few months, I learned not to be running with those kind. Tediously avoiding work, suddenly at 4 AM on Saturday Morning the level of effort and analytical functioning could only be described as "Expertise" ( note capitalization ) There has to be a solution else sites like Google and this one would not stand the chance of a dandelion in lightning bolt.There is a study in the mathematical works of cryptography whereby an institution ( with reputable goals ) can issue information - digital cash - that can exist on the open wire but does not reveal any information. Who would break them? My experience with [ person ]
shows that it is a study in socialization, depends on who you want to run with. What's the defense against sniffers if the code is already available more easily just using a browser?
vis a vis
So which one is valuable against attack? Neither, if someone wants to snag some Snake Oil from you, maybe you get the 2:59 am phone call that begins: "I'm an investor, we sunk thousands into your website. I just got a call from our security pro ....." all you can do to prepare for that moment is use established, known tools like SHA - of which the 256 variety is the acknowledged "next thing" - and have trace controls such that the security pro can put in on insurance and bonding.
Let alone trying to find one who knows how those tools work, their first line of defense is not talking to you ... then they have their own literature - they will want you to use their tools.
Then you don't get to code anything.