签名的会话Cookie。一个好主意？ [英] Signed session cookies. A good idea?

问题描述

为了提高性能，我想要消除一个简单的会话cookie，但加密cookie本身的所有信息。

A非常简单的例子：

  userid = 12345 
 time = now（）
 signature = hmac '，userid +：+ time，secret）; 
 
 cookie = userid +'：'+ time +'：'+ signature; 
  

时间将用于最长到期时间，因此Cookie不会永久生效。 p>

现在对于一个大问题：这是个坏主意吗？

我最好使用AES256吗？

EDIT

经过一些好的评论和评论后，我想补充一下：

• 唯一的每个用户和不可预测的（随机字符串+用户ID？）


• Cookie将自动过期（这是基于时间值+一定秒数）。 >
  
• 如果用户更改了密码，（或者甚至可以注销？）密码应该更改。

最后一个注意：我试图想出解决方案来减少数据库负载。这只是我调查的解决方案之一，但它是我最喜欢的。主要原因是我不必考虑其他存储机制更适合这种数据（memcache，nosql），它使得Web应用程序更加无状态。

解决方案

签署的令牌是任何想要发出令牌的好方法，能够验证您发出令牌，而不必在服务器端存储任何数据。这对于以下功能很有用：

• 时间限制帐户登录;


• 重置;


• 反XSRF表单;


• 时间限制表单提交（反垃圾邮件）。

它本身不是会话cookie的替代品，但如果它可以消除任何会话存储的需要，这可能是一件好事，即使性能差异

HMAC是生成签名令牌的一种合理方式。这不会是最快的;你可能能够逃脱一个简单的哈希如果你知道，可以避免扩展攻击。

我假设 hmac（）无论您使用的是什么语言，都已设置为使用合适的服务器端密钥，如果没有该密钥，您将无法拥有安全的已签名令牌。这个秘密必须是强大的和良好的保护，如果你要整个身份验证系统的基础。

为了登录和密码重置的目的，您可能需要为令牌添加额外的因素，密码生成数量。如果你喜欢，你可以重用数据库中的哈希密码的盐。这个想法是，当用户更改密码时，它应该使任何已发出的令牌失效（除了浏览器上的密码更改的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.

A very simple example:

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

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

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?

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

EDIT

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

• The 'secret' would be unique per-user and unpredictable (random string + user id ?)
• The cookie will expire automatically (this is done based on the time value + a certain amount of seconds).
• If a user changes their password, (or perhaps even logs out?) the secret should change.

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'.

解决方案

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:

• time-limited-account-login;
• password-resetting;
• anti-XSRF forms;
• time-limited-form-submission (anti-spam).

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 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.

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.

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。一个好主意？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！