如何在经典 ASP 中安全地设置基于 cookie 的身份验证？
在经典 ASP 网站中使用 cookie 来验证用户身份的最安全方法是什么？
我不想使用 ASP Session 对象，因为会话 cookie 一段时间后就会超时，并且我希望用户能够在单独的浏览器运行之间保持对网站的登录处于活动状态。
但是，我不想只创建一个包含用户 ID 的 cookie，因为这很容易伪造 - 那么我在这里有什么选择呢？我猜想是某种加密，但我真的不知道这样做的标准方法是什么。
What would be the most secure method of using cookies to authenticate users in a classic ASP website?
I don't want to use the ASP Session object as the session cookie times out after a while, and I'd like the user to be able to keep their login to the website active between separate browser runnings.
However, I don't want to just create a cookie containing their user ID as that could be easily forged - so what are my options here? I guess some sort of encryption but I don't really know what the standard methods of doing this is.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您在这里的选择非常有限。
让您的用户重新登录；最佳安全方法。
Your options here are pretty much limited.
Get your users to log back in again; best security approach.
这显然不仅仅适用于 ASP。
最好的方法是对密码进行哈希处理...在任何将密码存储在数据库中的情况下都应该这样做。
散列是一种加密函数 - 当您通过它运行一个字符串（例如密码）时，您会得到一个长代码。如果输入相同，则输出始终相同。
但是（这是重要的一点）从数学上来说几乎不可能逆转这个过程 - 从散列值开始并计算出密码，除了暴力（有人对字典或随机字符串进行散列并查找与他们的散列相匹配的输出）有）。
因此，当用户设置帐户时，他们输入所需的密码，但您对其进行散列并存储。类似地，在 cookie 中，他们登录后，您存储哈希值，而不是密码，并将其与数据库中的哈希值进行比较。
缺点是您无法发送密码提醒，因为您不知道密码 - 您必须发送密码重置链接并有一个系统来执行此操作。
如果你真的很偏执，你可能会双重哈希，例如，当他们登录时，密码会被哈希一次并存储在 cookie 中。然后再次对其进行哈希处理，并与 db 中的密码（也是经过双重哈希处理）进行比较。
This obviously applies much wider than just ASP.
The best way would be to hash the password... you should be doing this in any case where you store it in database.
The hash is a cryptographic function - when you run a string through it (eg password) you get out a long code. If the input is the same, the output is always the same.
But (this is the important bit) its mathematically virtually impossible to reverse the process - to start with the hashed value and work out the password, other than brute force (someone hashes dictionary, or random strings and looks for output that matches the hash they have).
So when the user sets up account, they put in their desired password, but you hash this, and store that. Similarly in the cookie, after they login you store the hash, not the password, and this has is compared with the hash in the db.
The downside is you can't send a password reminder since you don't know the password - to you'd have to send a password reset link and have a system to do that.
If you're really paranoid you might double hash, eg when they login the password is hashed once and stored in cookie. Its then hashed again and compared with the password in db (which is also double-hashed).
不要这样做
维护用户登录引用“...在单独的浏览器运行之间”是不安全的。恕我直言，当您关闭浏览器时，以前的登录信息应该会消失。假设您的访客在咖啡店使用社区电脑。
如果您保持此登录状态，则下一个社区用户可能会打开浏览器，导航到您的网站，并且“噗”他们会自动以以前的用户身份登录。
Don't Do It
Maintaining a user login quote "...between separate browser runnings" is not secure. IMHO, when you close the browser a previous login should be gone. Suppose your visitor was using a community pc at a coffee shop.
If you maintain this login the potential for the next community user to open the browser, navigate to your website and "poof" they are automatically logged in as the previous user.