哪种加密算法最适合加密 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 中存储任何需要加密的数据.相反，应在 cookie 中存储一个大小合适(128 位/16 字节)的随机密钥，并存储您想要确保安全的信息在服务器上，由 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:一个带有会话信息，另一个带有记住我"信息.

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

平台是 PHP 作为 VPS 上的 Linux 上的 apache 模块.

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 中存储一些数据，加密它的最佳方法是什么?

更新 3
对这个问题的回答让我重新考虑了所选择的方法.我确实可以在不需要加密的情况下做同样的事情.我应该只发送没有上下文的无意义数据，而不是加密数据并且无法猜测.

然而，我也不知所措:
我认为加密使我们能够将数据发送到 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:

• 一个长随机数，存储在数据库中并映射到用户帐户；
• 或包含例如的键控哈希(例如 HMAC)用户名、时间戳、mebbe 盐和秘密服务器密钥.这当然都可以在服务器端验证...

似乎我们对您的原始特定问题有点偏离主题 - 并通过更改设计更改了您的问题的基础....
因此，只要我们这样做，我也强烈推荐反对这种持久性记住我"的功能，原因有几个，其中最大的一个:

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