A client uses classic ASP to log in to their web based backoffice.
客户端使用经典的ASP登录到基于web的后台。
I have written a new ASP.Net app to be included in the backoffice, and I need to utilize the already existing login-system, so that when they are logged in there, they don't need to log in again in the new ASP.Net app.
我写了一个新的ASP。Net应用要包含在后台office中，我需要利用已经存在的登录系统，这样当他们登录到那里时，就不需要在新的ASP中再次登录。网络应用程序。
Logins and passwords are stored as clear text in a SQL Server db, that I can access from my ASP.Net app.
登录和密码以明文形式存储在SQL Server db中，我可以从ASP中访问。网络应用程序。
What would be an effective way to integrate these systems?
什么是整合这些系统的有效方法?
My current best idea is: In the link to my ASP.Net app, I link to a "gateway" login-page with their userid and a hashed password + common secret in the querystring. I then compare this to the password of the user in the database... But the problem is, that if this querystring is intercepted, it can be used to access the asp.net site, without actually knowing the username and password...
我目前最好的想法是:在我的ASP的链接。在Net应用程序中，我用用户id和查询字符串中的散列密码+公共秘密链接到一个“网关”登录页面。然后我将它与数据库中用户的密码进行比较……但是问题是，如果这个querystring被拦截，它可以用来访问asp.net站点，而实际上并不知道用户名和密码……
I am most likely overlooking something simple.
我很可能忽略了一些简单的东西。
5 个解决方案
#1
9
I think your idea is on the right path.
我认为你的想法是对的。
As you probably already know, classic asp and asp.net cannot share the same session state, so you do need to have a mechanism to log from one into the other.
您可能已经知道，经典的asp和asp.net不能共享相同的会话状态，所以您需要有一个机制来从一个会话状态登录到另一个会话状态。
What I would do is: when someone logs in, create a unique GUID that you save in the database for that user. When you jump from one site to the other, pass that GUID into the query string. When you try to auto-log them into the other site, look up that GUID and see if it's attached to anyone. If it is, log them in.
我要做的是:当有人登录时，创建一个惟一的GUID，并将其保存到数据库中以供该用户使用。当您从一个站点跳转到另一个站点时，将GUID传递到查询字符串。当您试图自动登录到另一个站点时，请查找GUID并查看它是否附加到任何人。如果是，登录它们。
This way you aren't passing anything that a user could guess or decrypt.
这样，您就不会传递任何用户可以猜到或解密的信息。
#2
4
How does the classic ASP system maintain login state? "Piggy-backing" off that would be your best bet, by far.
经典的ASP系统如何保持登录状态?到目前为止，这是你最好的选择。
All classic ASP systems I've worked on have used cookies for tracking authentication information, so just read those and compare against the database that you can access.
我研究过的所有经典的ASP系统都使用cookie来跟踪身份验证信息，所以只需读取这些信息并与您可以访问的数据库进行比较。
As the information is stored in a Classic ASP session, could you add a "redirect page" to the classic ASP side of things that is the "entrance" to the new module, and cause this to write the useful data out as cookies, or trigger a POST to your start page? By using cookies or a POST request, you minimise your worry about having the url "hijacked" allowing someone to get into the ASP.net site without username/password.
当信息存储在一个经典的ASP会话中，您是否可以添加一个“重定向页面”到新模块的“入口”的经典ASP方面，并使它将有用的数据写入cookie，或者触发一个POST到您的起始页?通过使用cookie或POST请求，您可以最小化对url“劫持”的担心，即允许某人不使用用户名/密码进入ASP.net站点。
#3
2
You are rightly worried about a MITM type attack, possibly through DNS cache poisoning or similar. Depending on your circumstances, it may be enough to mitigate the potential effects of this by adding a time constraint to the login token that is passed across the application boundaries.
您应该担心MITM类型的攻击，可能是通过DNS缓存中毒或类似的攻击。根据您的情况，通过向跨应用程序边界传递的登录令牌添加时间限制，可能足以减轻这种影响。
The 'GUID in the database approach' is something I have used successfully myself in the past, both for passing users between two applications sharing the same authentication database, and also for 'password reset email' type scenarios. You could 'expire' this by having an additional column on the record specifying the date at which the GUID was added, and modifying your application code to only log in GUID auths which are less than x minutes / hours / days old.
“GUID in The database approach”是我过去成功地使用过的一种方法，既用于在共享相同身份验证数据库的两个应用程序之间传递用户，也用于“密码重置电子邮件”类型场景。您可以通过在记录中添加一个额外的列来“过期”，指定添加GUID的日期，并将应用程序代码修改为只使用小于x分钟/小时/天的GUID auth。
An alternative could be to avoid additional fields in the database by concatenating something like:
另一种选择是通过连接以下内容来避免数据库中的其他字段:
UserId + [Value representing current time to nearest x minute / hour /day] + Salt
.. hashing it, then then duplicating your algorithm on the other application and comparing the two generated values.
. .对它进行散列，然后在另一个应用程序上复制算法，并比较生成的两个值。
In general, I think your proposed solution is appropriate to the problem. It is certainly not too complicated.
总的来说，我认为你提出的解决方案适合这个问题。这当然不太复杂。
#4
0
Couldn't you submit it via Form and not through the Querystring? That would eliminate the possibility of it being intercepted in the url.
难道你不能通过表单而不是查询字符串提交它吗?这将消除在url中被拦截的可能性。
#5
0
If interception is a serious issue then you need to be running the site over HTTPS. Otherwise using the UserID + Nonce that is then hashed by the password is reasonably strong.
如果拦截是一个严重的问题，那么您需要通过HTTPS运行站点。否则，如果使用UserID + Nonce，那么密码就会被加密。
Alternatively you could get the ASP app to add a GUID session cookie once logon has been acheived and store that GUID in a DB table. Your ASP.NET can look up the GUID from the cookie to see if logon has been acheived. If you include the ASP session cookie value in the table you can make reasonably sure that the current ASP session is the same session that was used when the GUID was created.
或者，您可以让ASP应用程序在登录成功后添加GUID会话cookie，并将该GUID存储在DB表中。你的ASP。NET可以从cookie中查找GUID，看看是否已经登录。如果在表中包含ASP会话cookie值，您可以合理地确保当前的ASP会话与创建GUID时使用的会话相同。
#1
9
I think your idea is on the right path.
我认为你的想法是对的。
As you probably already know, classic asp and asp.net cannot share the same session state, so you do need to have a mechanism to log from one into the other.
您可能已经知道，经典的asp和asp.net不能共享相同的会话状态，所以您需要有一个机制来从一个会话状态登录到另一个会话状态。
What I would do is: when someone logs in, create a unique GUID that you save in the database for that user. When you jump from one site to the other, pass that GUID into the query string. When you try to auto-log them into the other site, look up that GUID and see if it's attached to anyone. If it is, log them in.
我要做的是:当有人登录时，创建一个惟一的GUID，并将其保存到数据库中以供该用户使用。当您从一个站点跳转到另一个站点时，将GUID传递到查询字符串。当您试图自动登录到另一个站点时，请查找GUID并查看它是否附加到任何人。如果是，登录它们。
This way you aren't passing anything that a user could guess or decrypt.
这样，您就不会传递任何用户可以猜到或解密的信息。
#2
4
How does the classic ASP system maintain login state? "Piggy-backing" off that would be your best bet, by far.
经典的ASP系统如何保持登录状态?到目前为止，这是你最好的选择。
All classic ASP systems I've worked on have used cookies for tracking authentication information, so just read those and compare against the database that you can access.
我研究过的所有经典的ASP系统都使用cookie来跟踪身份验证信息，所以只需读取这些信息并与您可以访问的数据库进行比较。
As the information is stored in a Classic ASP session, could you add a "redirect page" to the classic ASP side of things that is the "entrance" to the new module, and cause this to write the useful data out as cookies, or trigger a POST to your start page? By using cookies or a POST request, you minimise your worry about having the url "hijacked" allowing someone to get into the ASP.net site without username/password.
当信息存储在一个经典的ASP会话中，您是否可以添加一个“重定向页面”到新模块的“入口”的经典ASP方面，并使它将有用的数据写入cookie，或者触发一个POST到您的起始页?通过使用cookie或POST请求，您可以最小化对url“劫持”的担心，即允许某人不使用用户名/密码进入ASP.net站点。
#3
2
You are rightly worried about a MITM type attack, possibly through DNS cache poisoning or similar. Depending on your circumstances, it may be enough to mitigate the potential effects of this by adding a time constraint to the login token that is passed across the application boundaries.
您应该担心MITM类型的攻击，可能是通过DNS缓存中毒或类似的攻击。根据您的情况，通过向跨应用程序边界传递的登录令牌添加时间限制，可能足以减轻这种影响。
The 'GUID in the database approach' is something I have used successfully myself in the past, both for passing users between two applications sharing the same authentication database, and also for 'password reset email' type scenarios. You could 'expire' this by having an additional column on the record specifying the date at which the GUID was added, and modifying your application code to only log in GUID auths which are less than x minutes / hours / days old.
“GUID in The database approach”是我过去成功地使用过的一种方法，既用于在共享相同身份验证数据库的两个应用程序之间传递用户，也用于“密码重置电子邮件”类型场景。您可以通过在记录中添加一个额外的列来“过期”，指定添加GUID的日期，并将应用程序代码修改为只使用小于x分钟/小时/天的GUID auth。
An alternative could be to avoid additional fields in the database by concatenating something like:
另一种选择是通过连接以下内容来避免数据库中的其他字段:
UserId + [Value representing current time to nearest x minute / hour /day] + Salt
.. hashing it, then then duplicating your algorithm on the other application and comparing the two generated values.
. .对它进行散列，然后在另一个应用程序上复制算法，并比较生成的两个值。
In general, I think your proposed solution is appropriate to the problem. It is certainly not too complicated.
总的来说，我认为你提出的解决方案适合这个问题。这当然不太复杂。
#4
0
Couldn't you submit it via Form and not through the Querystring? That would eliminate the possibility of it being intercepted in the url.
难道你不能通过表单而不是查询字符串提交它吗?这将消除在url中被拦截的可能性。
#5
0
If interception is a serious issue then you need to be running the site over HTTPS. Otherwise using the UserID + Nonce that is then hashed by the password is reasonably strong.
如果拦截是一个严重的问题，那么您需要通过HTTPS运行站点。否则，如果使用UserID + Nonce，那么密码就会被加密。
Alternatively you could get the ASP app to add a GUID session cookie once logon has been acheived and store that GUID in a DB table. Your ASP.NET can look up the GUID from the cookie to see if logon has been acheived. If you include the ASP session cookie value in the table you can make reasonably sure that the current ASP session is the same session that was used when the GUID was created.
或者，您可以让ASP应用程序在登录成功后添加GUID会话cookie，并将该GUID存储在DB表中。你的ASP。NET可以从cookie中查找GUID，看看是否已经登录。如果在表中包含ASP会话cookie值，您可以合理地确保当前的ASP会话与创建GUID时使用的会话相同。