HTTP 记住我身份验证
我正在尝试为用户编写一个简单的 HTTP 记住我身份验证系统。
我的用户可以这样表示
{
"email" : "[email protected]",
"password" : "8EC41F4334C1B9615F930270A4F8BBC2F5A2FCD3" // sha1 hash of password
}
所以我的想法是我需要创建一个具有无限期(非常长)过期时间的cookie,它将保存某种类型的信息,使我能够从数据库中获取用户,从而记录用户 我的第一个
想法是简单地将 email:password
字符串存储为 cookie。我认为这很好,因为除了用户本身之外,没有其他人可以真正生成此类信息,并且我可以通过简单地比较用户名
和密码 基于数据库中的内容。
但后来我觉得这不太好。它将密码摘要有效地转换为第二个密码,该密码以明文形式存储并在每个请求中通过网络传递。
所以后来我想也许我可以在用户每次登录时生成一个签名,这基本上是一个直接存储在数据库中的用户对象中的随机哈希。
用户登录后,会生成存储的签名,并且 cookie 保存该签名。每当您访问该网站时,该网站都会检查哪个用户具有该特定签名并让该用户登录。注销将有效删除 cookie,新的登录将生成新的随机签名。
这种方法是否考虑到任何其他漏洞?
我知道,我可能应该使用为此创建的库,但这只是网络安全方面的一个练习。
I'm trying to write a simple HTTP remember me authentication system for users.
My users could be represented as such
{
"email" : "[email protected]",
"password" : "8EC41F4334C1B9615F930270A4F8BBC2F5A2FCD3" // sha1 hash of password
}
So my idea is that I need to create a cookie, with indefinite (really long) expiration time, that will hold some type of information to enable me to fetch the user from the database, therefore logging the user in.
My first idea was to just simply store the email:password
string as a cookie. I thought this would be good since nobody else can really generate that type of information other than the user itself, and I could retrieve the user quite easily by simply comparing the username
and password
based on what's in the database.
However then I thought this wasn't really good. It turns the password digest into, effectively, a second password that's stored in the clear and passed over the wire in every request.
So then I thought maybe I could generate a signature
each time the user logs in, which would basically be a random hash that is stored directly in the user object in the database.
The user logs in, it generates this signature that is stored, and the cookie holds this signature. Whenever you access the website, the site checks which user has that particular signature and logs the user in. Logging out will effectively erase the cookie, and new logins will generate a new random signature.
Does this approach take into account any other vulnerabilities?
I know, I should probably use a library already made for this, but this is just simply an exercise in web-security.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
这本质上是大多数网站在您登录时所做的事情。是的,cookie 应该保存用户“会话”的唯一标识符。 cookie 本质上应该是随机的。由您决定是否使其在浏览器会话中保持不变。
除了身份验证数据库中的 cookie 之外,还存储创建条目的时间戳。超过 N 秒的 Cookie 应被视为无效(根据您的喜好设置 N)。您可以在每次使用 cookie 时重置时间戳,以便空闲会话超时。
请注意,同一用户可能希望拥有多个会话(您是否曾经从家庭和工作场所登录过您的电子邮件帐户?),因此这里的概念实际上是“会话”,而不是用户。
This is essentially what most sites do when you log in. Yes, the cookie should hold a unique identifier for the user's "session". The cookie should be essentially random. Up to you whether to make it persistent across browser sessions.
Along with the cookie in your authentication DB, also store a timestamp of when the entry was created. Cookies older than N seconds should be considered invalid (set N to your taste). You can reset the timestamp each time the cookie is used so that idle sessions time out.
Note that the same user may want to have multiple sessions (do you ever log in to your Email account from both home and work?), so the concept here really is "session", not user.
两者的漏洞观点是相同的! Cookie 窃取和相关机制但是浏览器现在足够智能,因此您不必担心这一点。
第二种方法在隐私方面也很好,因为它在 cookie 中不包含电子邮件地址。它看起来更类似于存储 sessionID,在您的情况下,您生成一个随机哈希并将其存储在数据库中。
但我认为使用第一种方法会更明智;您可以在摘要中添加另一层并使用您的一些算法或私钥对其进行加密;为了更安全。
Vulnerability point-of-view both are same! Cookie stealing and related mechanisms however browsers are smart enough now so you shouldn't worry about that.
Second approach is good in terms of privacy as well since it does not includes email address in the cookie. And it seems much more similar to like storing the sessionID which in your case you are generating a random hash and storing it in DB.
But i think it would be more wiser to use the first approach; you can add another layer to the digest and encrypt it with your some algo or private key; to be on safer side.