本文介绍了签名的会话 cookie.一个好主意?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

为了提高性能,我想尝试消除一个普通的会话 cookie",但对 cookie 本身中的所有信息进行加密.

In an effort to increase performance, I was thinking of trying to eliminate a plain 'session cookie', but encrypt all the information in the cookie itself.

一个非常简单的例子:

userid= 12345
time=now()
signature = hmac('SHA1',userid + ":" + time, secret);

cookie = userid + ':' + time + ':' + signature;

该时间将用于最长到期时间,因此 cookie 不会永远存在.

The time would be used for a maximum expirytime, so cookies won't live on forever.

现在是一个大问题:这是一个坏主意吗?

Now for the big question: is this a bad idea?

我最好改用 AES256 吗?在我的情况下,数据不是机密的,但在任何情况下都不得更改.

Am I better off using AES256 instead? In my case the data is not confidential, but it must not be changed under any circumstances.

编辑

经过一些好的批评和评论后,我想补充一下:

After some good critique and comments, I'd like to add this:

  • 秘密"将是每个用户唯一且不可预测的(随机字符串 + 用户 ID?)
  • cookie 将自动过期(这是根据时间值 + 一定的秒数来完成的).
  • 如果用户更改了他们的密码,(或者甚至注销?)秘密应该改变.

最后一点:我正在尝试提出减少数据库负载的解决方案.这只是我正在研究的解决方案之一,但它是我最喜欢的.主要原因是我不必研究更适合此类数据的其他存储机制(memcache、nosql),它使 Web 应用程序更加无状态".

A last note: I'm trying come up with solutions to decrease database load. This is only one of the solutions I'm investigating, but it's kind of my favourite. The main reason is that I don't have to look into other storage mechanism better suited for this kind of data (memcache, nosql) and it makes the web application a bit more 'stateless'.

10 年后编辑

JWT 现在是一回事.

JWT is now a thing.

推荐答案

签名令牌是一种很好的方法,适用于您想要颁发令牌的任何事情,然后在返回时能够验证您是否颁发了令牌,无需在服务器端存储任何数据.这适用于以下功能:

A signed token is a good method for anything where you want to issue a token and then, when it is returned, be able to verify that you issued the token, without having to store any data on the server side. This is good for features like:

  • 限时登录;
  • 密码重置;
  • 反 XSRF 形式;
  • 限时提交(反垃圾邮件).

它本身并不是会话 cookie 的替代品,但如果它可以完全消除对任何会话存储的需求,那可能是一件好事,即使性能差异不会很大.

It's not in itself a replacement for a session cookie, but if it can eliminate the need for any session storage at all that's probably a good thing, even if the performance difference isn't going to be huge.

HMAC 是生成签名令牌的一种合理方式.它不会是最快的.如果您知道并且可以避免扩展攻击,您可能可以通过简单的哈希来逃脱.我会让你来决定这对你来说是否值得冒险.

HMAC is one reasonable way of generating a signed token. It's not going to be the fastest; you may be able to get away with a simple hash if you know about and can avoid extension attacks. I'll leave you to decide whether that's worth the risk for you.

我假设 hmac() 在您使用的任何语言中都已设置为使用合适的服务器端密钥,否则您将无法获得安全的签名的令牌.如果您要围绕它建立整个身份验证系统,那么这个秘密必须很强大并且受到很好的保护.如果你必须改变它,每个人都会被注销.

I'm assuming that hmac() in whatever language it is you're using has been set up to use a suitable server-side secret key, without which you can't have a secure signed token. This secret must be strong and well-protected if you are to base your whole authentication system around it. If you have to change it, everyone gets logged out.

出于登录和密码重置的目的,您可能需要为令牌添加一个额外的因素,即密码生成编号.如果您愿意,您可以在数据库中重新使用散列密码的盐.这个想法是,当用户更改密码时,它应该使任何已发布的令牌无效(除了浏览器上的 cookie 进行密码更改,它会被重新发布的令牌替换).否则,发现其帐户已被盗用的用户无法锁定其他方.

For login and password-resetting purposes you may want to add an extra factor to the token, a password generation number. You can re-use the salt of the hashed password in the database for this if you like. The idea is that when the user changes passwords it should invalidate any issued tokens (except for the cookie on the browser doing the password change, which gets replaced with a re-issued one). Otherwise, a user discovering their account has been compromised cannot lock other parties out.

这篇关于签名的会话 cookie.一个好主意?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

08-21 18:16