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

问题描述

由于这个问题很受欢迎，我认为给它一个更新是有用的。

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

让我强调正确回答，由 AviD 提供给此问题：

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

您不应将任何需要加密的数据存储在您的cookie中。相反，将一个很好的大小（128位/ 16字节）随机密钥存储在cookie中，将要保存的信息存储在服务器上，由Cookie的密钥标识。

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.

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

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

我遵循以下要求：

• 必须快速
  
  加密和解密数据将要完成（几乎）每个请求

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

它将对小数据集（通常是字符串）约100个字符以内

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

我们需要能够解密信息，所以SHA1等等。

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

现在我已经看到，Blowfish是快速和安全的，我已经阅读AES是快速和安全的。
Blowfish具有较小的块大小。

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.

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

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.

所以我的问题是：

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

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

更新

更准确地说，我们要加密2个cookie：一个具有会话信息，另一个使用'remeber me'信息。

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

该平台是PHP作为Linux上的apache模块，在VPS上。

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

更新2

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

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

但是，我们有一个要求实现重建我功能。接受的方法是设置一个cookie。如果客户端提供此cookie，则允许他/她以（几乎）相同的权限访问系统，就像他/她呈现有效的用户名密码组合一样。

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.

所以我们至少要加密Cookie中的所有数据，以便：

a）恶意用户无法读取其内容，

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

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.

（Cookie的所有数据都被清理并检查有效性，然后再进行任何操作它，但这是另一个故事）

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

会话cookie包含一个sessionId / timestamp没有更多。它可能没有加密使用，但是我看不到加密它有什么危害？ （除了计算时间）。

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

因此，鉴于我们必须在cookie中存储一些数据，加密的最好方法是什么？ em>

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

更新3

对这个问题的回复让我重新考虑了所选择的方法。我可以做同样的事情，而不需要加密。而不是加密数据，我不应该发出没有上下文的emo数据，而且不能被猜到。

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.

但是，我也在亏损：

我认为加密使我们能够将数据发送到BigBadWorld™而且（相当地）肯定没有人可以读取或篡改它...

这不是整个加密点吗？

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.

我缺少什么？

推荐答案

没有真正的原因不能与 AES 与256位。请确保在 CBC模式和PKCS＃7中使用填充。
正如你所说，快速安全。

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.

我已阅读（未经测试），Blowfish可能会略微更快...但是，Blowfish有长的安装时间的主要缺点，这将使您的情况不好。此外，AES更被证明。

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

这假设它真正地需要对对称加密您的cookie数据。正如其他人所指出的，真的不应该是必要的，只有一些边缘的情况，除了这样做之外别无选择。通常情况下，更适合您更改设计，并返回到随机会话标识符，或者必要时使用单向散列（使用SHA-256）。

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

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:

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


• 或包含eg用户名，时间戳，mebbe一个盐，和一个秘密服务器密钥。这当然可以通过服务器端进行验证...

看起来我们已经得到了一些你原来的话题，具体问题 - 通过改变设计来改变你的问题的基础....

所以只要我们这样做，我也会强烈推荐 AGAINST 这个功能持续的记住我，由于几个原因，其中最大的：

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:

• 使人更有可能窃取用户的记忆密钥，允许他们欺骗用户的身份（然后可能改变他的密码）;


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

• 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屋！