什么加密算法最适合加密Cookie? [英] What encryption algorithm is best for encrypting cookies?

查看:275
本文介绍了什么加密算法最适合加密Cookie?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述


由于这个问题相当受欢迎,我认为给它一个更新很有用。



让我强调回答,由 AviD 提供给此问题:



您不应将任何需要加密的数据存储在Cookie中。而是在Cookie中存储一个大小(128位/ 16位)的随机密钥,



$ b请输入您要保存的安全信息
$ b


我在寻找有关加密cookie的最佳加密算法的信息。



我有以下要求:




  • 必须快速

    加密和解密数据


  • 它会对小数据集(通常大约100个字符或更少的字符串)进行操作


  • 它必须安全,但它不像我们正在确保银行交易


  • 我们需要能够解密信息如SHA1等。




现在我已经阅读了Blowfish的快速和安全,我读过AES是快速和安全。
具有较小块大小的Blowfish。



我认为这两种算法都提供了足够的安全性?因此速度将成为决定性因素。
但我真的不知道这些算法是否适合小字符串,如果有可能更适合的算法加密cookie。



所以我的问题是:

什么加密算法最适合加密Cookie数据?



更新 >
为了更精确,我们要加密2个cookie:一个具有会话信息,另一个具有'remeber me'信息。





更新2

我同意 cletus 在Cookie中存储任何信息是不安全的。



但是,我们有一个要求实施重新记录我功能。接受的方式是通过设置一个cookie。如果客户端提供此Cookie,则允许他/她(几乎)享有与提供有效用户名密码组合相同的权利。



至少要加密Cookie中的所有数据,以便:

a)恶意用户无法读取其内容,

b )恶意用户无法制作自己的Cookie或篡改它。



(我们执行任何操作之前,Cookie中的所有数据都已清除并检查有效性它是另一个故事)



会话cookie只包含sessionId /时间戳。它可能在没有加密的情况下使用,但我认为加密它没有害处? (除了计算时间)。



因此,假设我们必须在cookie中存储一些数据,最好的加密方式是什么? em>



更新3

对此问题的回复让我重新考虑所选择的方法。我确实可以做同样,而不需要加密。



不是加密数据,而是发送没有上下文无意义的数据。我也失去了:

我认为加密使我们能够发送数据到BigBadWorld™,仍然(相当地)没有人可以读或篡改它...

这不是整个加密点吗?



但是下面的反应推向:不信任加密以实现安全性。

解决方案



<

没有什么理由不使用256位的 AES 。请务必在 CBC模式和PKCS# 7填充。
正如你所说,快速和安全。



我已经阅读(未测试)Blowfish可能会稍快一些...但是Blowfish有一个主要的缺点,长的建立时间,这将使它不利于你的情况。此外,AES更被证明。



这假设真正需要对称加密您的Cookie资料 。正如其他人所指出的,它真的不应该是必要的,只有少数边缘情况下,没有别的选择,但这样做。通常,它更适合您更改设计,并返回到随机会话标识符,或者如果必要,单向哈希(使用SHA-256)。

在您的情况下,除了常规随机会话标识符,您的问题是记住我功能 - 这也应该实现为




  • 一个长随机数,存储在数据库中并映射到用户帐户;

  • 或键控散列(例如HMAC)包含例如用户名,时间戳,盐,和秘密服务器密钥。这当然可以验证服务器端...



似乎我们已经得到了一些关于您的原始主题,具体的问题 - 并通过改变设计改变了你的问题的基础....

只要我们这样做,我也强烈建议 此功能持续的记住我,原因有几个,其中最大的:




  • 更有可能有人窃取用户的记忆密钥,允许他们欺骗用户的身份(然后可能更改密码);

  • CSRF - 跨网站请求伪造。您的功能将有效地允许匿名攻击者导致未知用户向您的应用程序提交已验证的请求,即使实际上未登录。


Since this question is rather popular, I thought it useful to give it an update.

Let me emphasise the correct answer as given by AviD to this question:

You should not store any data that needs encrypting in your cookie. Instead, store a good sized (128 bits/16 bytes) random key in the cookie and store the information you want to keep secure on the server, identified by the cookie's key.



I'm looking for information about 'the best' encryption algorithm for encrypting cookies.

I hava the following requirements:

  • It must be fast
    encrypting and decrypting the data will be done for (nearly) every request

  • It will operate on small data sets, typically strings of around 100 character or less

  • It must be secure, but it's not like we're securing banking transactions

  • We need to be able to decrypt the information so SHA1 and the like are out.

Now I've read that Blowfish is fast and secure, and I've read that AES is fast and secure. With Blowfish having a smaller block size.

I think that both algorithms provide more than adequate security? so the speed would then become the decisive factor. But I really have no idea if those algorithm are suited for small character string and if there are maybe better suited algorithm for encrypting cookies.

So my question is:
What encryption algorithm is best for encrypting cookie data?

Update
To be more precise, we want to encrypt 2 cookie: one with session information and the other with 'remeber me' information.

The platform is PHP as apache module on Linux on a VPS.

Update 2
I agree with cletus that storing any information in a cookie is insecure.

However, we have a requirement to implement a 'remeber me' feature. The accepted way to go about this is by setting a cookie. If the client presents this cookie, he or she is allowed access the system with (almost) equal rights as if he/she presented the valid username password combination.

So we at least want to encrypt all data in the cookie so that it:
a) malicious users can't read it's contents,
b) malicious users can't fabricate their own cookie or tamper with it.

(All data from cookies is sanitized and checked for validity before we do anything with it, but that's another story)

The session cookie contains a sessionId/timestamp nothing more. It could probably be used without encryption, but I see no harm in encrypting it? (other than computation time).

So given that we have to store some data on in a cookie, what is the best way to encrypt it?

Update 3
The responses to this question made me reconsider the chosen approach. I can indeed do the same without the need for encryption. Instead of encrypting the data, I should only send out data that is meaningless without it's context and cannot be guessed.

However, I'm also at a loss:
I thought that encryption enabled us send data out in to the BigBadWorld™, and still be (fairly) sure that nobody could read or tamper with the it...
Wasn't that the whole point of encryption?

But the reactions below push toward: Do not trust encryption to accomplish security.

What am I missing??

解决方案

No real reason not to go with AES with 256 bits. Make sure to use this in CBC mode, and PKCS#7 padding. As you said, fast and secure.

I have read (not tested) that Blowfish may be marginally faster... However Blowfish has a major drawback of long setup time, which would make it bad for your situation. Also, AES is more "proven".

This assumes that it really is necessary to symmetrically encrypt your cookie data. As others have noted, it really shouldnt be necessary, and there are only a few edge cases where there's no other choice but to do so. Commonly, it would better suit you to change the design, and go back to either random session identifiers, or if necessary one-way hashes (using SHA-256).
In your case, besides the "regular" random session identifier, your issue is the "remember me" feature - this should also be implemented as either:

  • a long random number, stored in the database and mapped to a user account;
  • or a keyed hash (e.g. HMAC) containing e.g. the username, timestamp, mebbe a salt, AND a secret server key. This can of course all be verified server-side...

Seems like we've gotten a little off topic of your original, specific question - and changed the basis of your question by changing the design....
So as long as we're doing that, I would also STRONGLY recommend AGAINST this feature of persistent "remember me", for several reasons, the biggest among them:

  • Makes it much more likely that someone may steal that user's remember key, allowing them to spoof the user's identity (and then probably change his password);
  • CSRF - Cross Site Request Forgery. Your feature will effectively allow an anonymous attacker to cause unknowing users to submit "authenticated" requests to your application, even without being actually logged in.

这篇关于什么加密算法最适合加密Cookie?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆