php 哪种加密算法最适合加密 cookie？

What encryption algorithm is best for encrypting cookies?

提问by Jacco

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

Let me emphasise the correct answeras given by AviDto 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.

由于这个问题相当流行，我认为对其进行更新很有用。

让我强调AviD对这个问题给出的正确答案：

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

---

---

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

我正在寻找有关用于加密 cookie 的“最佳”加密算法的信息。

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.

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

• 它将在小数据集上运行，通常是大约 100 个字符或更少的字符串

• 它必须是安全的，但这不像我们在保护银行交易

• 我们需要能够解密信息，这样 SHA1 之类的东西就出来了。

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.

现在我读到 Blowfish 既快速又安全，而且我读到 AES 又快又安全。Blowfish 具有较小的块大小。

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?

所以我的问题是：
哪种加密算法最适合加密 cookie 数据？

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

更新
更准确地说，我们要加密 2 个 cookie：一个带有会话信息，另一个带有“记住我”信息。

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

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

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

更新 2
我同意cletus 的观点，即在 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。如果客户端提供此 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 中的所有数据进行加密，以便：
a)恶意用户无法读取其内容，
b)恶意用户无法伪造或篡改自己的 cookie。

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

（在我们对 cookie 做任何事情之前，所有来自 cookie 的数据都经过消毒并检查其有效性，但那是另一回事了）

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 仅包含 sessionId/timestamp。它可能可以在不加密的情况下使用，但我认为加密它没有害处？（计算时间除外）。

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

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

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.

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

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?

然而，我也不知所措：
我认为加密使我们能够将数据发送到 BigBadWorld™，并且仍然（相当）确定没有人可以读取或篡改它......
这不是全部加密点？

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

但是下面的反应是：不要相信加密来实现安全。

What am I missing??

我错过了什么？？

采纳答案by AviD

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

没有真正的理由不使用 256 位的AES。确保在CBC 模式和 PKCS#7 填充中使用它。正如您所说，快速且安全。

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

我读过（未测试）Blowfish 可能稍微快一点……但是 Blowfish 有一个主要缺点，即设置时间长，这对您的情况不利。此外，AES 更“成熟”。

This assumes that it really isnecessary 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:

这假设确实有必要对称加密您的 cookie 数据。正如其他人所指出的，这真的没有必要，并且只有少数极端情况下别无选择，只能这样做。通常，更改设计并返回到随机会话标识符或在必要时使用单向哈希（使用 SHA-256）会更适合您。
在您的情况下，除了“常规”随机会话标识符之外，您的问题是“记住我”功能 - 这也应该实现为：

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

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

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

• 使某人更有可能窃取该用户的记忆密钥，从而使他们能够欺骗用户的身份（然后可能更改他的密码）；
• CSRF-跨站请求伪造。您的功能将有效地允许匿名攻击者导致不知情的用户向您的应用程序提交“经过身份验证的”请求，即使没有实际登录。

回答by cletus

This is touching on two separate issues.

这涉及两个不同的问题。

Firstly, session hiHymaning. This is where a third party discovers, say, an authenticated cookie and gains access to someone else's details.

首先，会话劫持。这是第三方发现，例如，经过身份验证的 cookie 并获得访问其他人详细信息的地方。

Secondly, there is session data security. By this I mean that you store data in the cookie (such as the username). This is not a good idea. Any such data is fundamentally untrustworthy just like HTML form data is untrustworthy (irrespective of what Javascript validation and/or HTML length restrictions you use, if any) because a client is free to submit what they want.

其次，有会话数据安全性。我的意思是您将数据存储在 cookie 中（例如用户名）。这不是一个好主意。任何此类数据从根本上都是不可信的，就像 HTML 表单数据不可信一样（无论您使用什么 Javascript 验证和/或 HTML 长度限制，如果有的话），因为客户端可以自由提交他们想要的内容。

You'll often find people (rightly) advocating sanitizing HTML form data but cookie data will be blindly accepted on face value. Big mistake. In fact, I never store any information in the cookie. I view it as a session key and that's all.

你经常会发现人们（正确地）提倡清理 HTML 表单数据，但 cookie 数据会被盲目地接受。大错。事实上，我从不在 cookie 中存储任何信息。我将其视为会话密钥，仅此而已。

If you intend to store data in a cookie I strongly advise you to reconsider.

如果您打算将数据存储在 cookie 中，我强烈建议您重新考虑。

Encryption of this data does not make the information any more trustworth because symmetric encryption is susceptible to brute-force attack. Obviously AES-256 is better than, say, DES (heh) but 256-bits of security doesn't necessarily mean as much as you think it does.

对这些数据进行加密不会使信息更值得信赖，因为对称加密容易受到蛮力攻击。显然 AES-256 比 DES 好（呵呵），但是 256 位的安全性并不一定像您认为的那样重要。

For one thing, SALTs are typically generated according to an algorithm or are otherwise susceptible to attack.

一方面，SALT 通常是根据算法生成的，否则很容易受到攻击。

For another, cookie data is a prime candidate for cribattacks. If it is known or suspected that a username is in the encrypted data will hey, there's your crib.

另一方面，cookie 数据是婴儿床攻击的主要候选者。如果知道或怀疑用户名在加密数据中，嘿，这是您的婴儿床。

This brings us back to the first point: hiHymaning.

这让我们回到第一点：劫持。

It should be pointed out that on shared-hosting environments in PHP (as one example) your session data is simply stored on the filesystem and is readable by anyone else on that same host although they don't necessarily know which site it is for. So never store plaintext passwords, credit card numbers, extensive personal details or anything that might otherwise be deemed as sensitive in session data in such environments without some form of encryption or, better yet, just storing a key in the session and storing the actual sensitive data in a database.

应该指出的是，在 PHP 中的共享托管环境（作为一个示例）中，您的会话数据只是存储在文件系统中，并且可以被同一主机上的任何其他人读取，尽管他们不一定知道它是用于哪个站点的。因此，在没有某种形式的加密的情况下，永远不要存储明文密码、信用卡号、大量个人详细信息或任何可能在会话数据中被视为敏感的内容，或者更好的是，只在会话中存储密钥并存储实际敏感信息。数据库中的数据。

Note:the above is not unique to PHP.

注意：以上不是 PHP 独有的。

But that's server side encryption.

但那是服务器端加密。

Now you could argue that encrypting a session with some extra data will make it more secure from hiHymaning. A common example is the user's IP address. Problem is many people use the same PC/laptop at many different locations (eg Wifi hotspots, work, home). Also many environments will use a variety of IP addresses as the source address, particularly in corporate environments.

现在您可能会争辩说，使用一些额外数据加密会话将使其更安全，不会被劫持。一个常见的例子是用户的 IP 地址。问题是许多人在许多不同的地点（例如 Wifi 热点、工作场所、家中）使用相同的 PC/笔记本电脑。此外，许多环境将使用各种 IP 地址作为源地址，尤其是在企业环境中。

You might also use the user agent but that's guessable.

您也可以使用用户代理，但这是可以猜测的。

So really, as far as I can tell, there's no real reason to use cookie encryption at all. I never did think there was but in light of this question I went looking to be proven either right or wrong. I found a few threads about people suggesting ways to encrypt cookie data, transparently do it with Apache modules, and so on but these all seemed motivated by protecting data stored in a cookie (which imho you shouldn't do).

所以真的，据我所知，根本没有真正的理由使用 cookie 加密。我从来没有想过有，但鉴于这个问题，我开始寻求证明是对还是错。我发现了一些关于人们建议加密 cookie 数据的方法的线程，使用 Apache 模块透明地进行加密等等，但这些似乎都是出于保护存储在 cookie 中的数据的动机（恕我直言，您不应该这样做）。

I've yet to see a security argument for encrypting a cookie that represents nothing more than a session key.

我还没有看到用于加密仅代表会话密钥的 cookie 的安全参数。

I will happily be proven wrong if someone can point out something to the contrary.

如果有人能指出相反的事情，我会很高兴被证明是错误的。

回答by Xeoncross

Security Warning: These two functions are not secure. They're using ECB modeand fail to authenticate the ciphertext. See this answerfor a better way forward.

安全警告：这两个功能不安全。他们正在使用ECB 模式并且无法验证密文。请参阅此答案以获得更好的前进方式。

For those reading through wanting to use this method in PHP scripts. Here is a working example using 256bit Rijndael (not AES).

对于那些希望在 PHP 脚本中使用此方法的人阅读。这是一个使用 256 位 Rijndael（不是 AES）的工作示例。

function encrypt($text, $salt) 
{ 
    return trim(base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $salt, $text, MCRYPT_MODE_ECB, mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB), MCRYPT_RAND)))); 
} 

function decrypt($text, $salt) 
{ 
    return trim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, $salt, base64_decode($text), MCRYPT_MODE_ECB, mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB), MCRYPT_RAND))); 
}

Then to save the cookie

然后保存cookie

setcookie("PHPSESSION", encrypt('thecookiedata', 'longsecretsalt'));

and to read on the next page:

并阅读下一页：

$data = decrypt($_COOKIE['PHPSESSION'], 'longsecretsalt');

回答by Scott Arciszewski

Fast, Encrypted Cookies with Libsodium

使用 Libsodium 的快速加密 Cookie

If you need fast, secure encrypted cookies in PHP, check out how Haliteimplements them. Halite relies on the libsodium PECL extensionto provide secure cryptography.

如果您需要 PHP 中快速、安全的加密 cookie，请查看Halite如何实现它们。Halite依靠libsodium PECL 扩展来提供安全加密。

<?php
use \ParagonIE\Halite\Cookie;
use \ParagonIE\Halite\Symmetric\Key;
use \ParagonIE\Halite\Symmetric\SecretKey;

// You can also use Key::deriveFromPassword($password, $salt, Key::CRYPTO_SECRETBOX);
$encryption_key = new SecretKey($some_constant_32byte_string_here);

$cookie = new Cookie($encryption_key);

$cookie->store('index', $any_value);
$some_value = $cookie->fetch('other_index');

If you cannot install PECL extensions, ask your sysadmin or hosting provider to do it for you. If they refuse, you still have options.

如果您无法安装 PECL 扩展，请让您的系统管理员或托管服务提供商为您安装。如果他们拒绝，你仍然有选择。

---

---

Secure Encrypted Cookies in PHP, Hold the Salt Please

PHP 中的安全加密 Cookie，请保持盐度

The other answers instruct you to encrypt your data with openssl or mcrypt, but they're missing a crucial step. If you want to safely encrypt data in PHP, you mustauthenticate your messages.

其他答案指示您使用 openssl 或 mcrypt 加密数据，但它们缺少关键步骤。如果您想在 PHP 中安全地加密数据，您必须对您的消息进行身份验证。

Using the OpenSSL extension, the process you would need to follow looks like this:

使用 OpenSSL 扩展，您需要遵循的过程如下所示：

---

---

Preamble

前言

• (Before you even think about encryption) Generate a 128-bit, 192-bit, or 256-bit random string. This will be your master key.

  Do not use a human-readable password.If you, for some reason, mustuse a human-readable password, ask Cryptography SEfor guidance.

  If you need special attention, my employer offers technology consulting services, including development of cryptography features.

• （在您考虑加密之前）生成 128 位、192 位或 256 位随机字符串。这将是您的主密钥。

  不要使用人类可读的密码。如果您出于某种原因必须使用人类可读的密码，请向Cryptography SE寻求指导。

  如果您需要特别关注，我的雇主提供技术咨询服务，包括密码学功能的开发。

Encryption

加密

1. Generate a random Initialization Vector (IV) or nonce. e.g. random_bytes(openssl_cipher_iv_length('aes-256-cbc'))
2. Use HKDFor a similar algorithm for splitting your master key into two keys:
   1. An encryption key ($eKey)
   2. An authentication key ($aKey)
3. Encrypt your string with openssl_encrypt()with your IV and an appropriate modate (e.g. aes-256-ctr) using your encryption key ($eKey) from step 2.
4. Compute an authentication tag of your ciphertext from step 3, using a keyed hash function such as HMAC-SHA256. e.g. hash_hmac('sha256', $iv.$ciphertext, $aKey). It's very important to authenticate after encryption, and to encapsulate the IV/nonce as well.
5. Package the authentication tag, IV or nonce, and ciphertext together and optionally encode it with bin2hex()or base64_encode(). (Warning: This approach mightleak cache-timing information.)

1. 生成随机初始化向量 (IV) 或随机数。例如random_bytes(openssl_cipher_iv_length('aes-256-cbc'))
2. 使用HKDF或类似算法将您的主密钥拆分为两个密钥：
   1. 加密密钥 ( $eKey)
   2. 身份验证密钥 ( $aKey)
3. openssl_encrypt()使用您的 IV 和适当的模式（例如aes-256-ctr）使用$eKey步骤 2 中的加密密钥 ( )加密您的字符串。
4. 使用密钥散列函数（例如 HMAC-SHA256）计算步骤 3 中密文的身份验证标记。例如hash_hmac('sha256', $iv.$ciphertext, $aKey)。加密后进行身份验证以及封装 IV/nonce 非常重要。
5. 将身份验证标签、IV 或随机数和密文打包在一起，并可选择使用bin2hex()或 对其进行编码base64_encode()。（警告：这种方法可能会泄漏缓存时间信息。）

Decryption

解密

1. Split your key, as per step 2 in encryption. We need the same two keys during decryption!
2. (Optionally, decode and) unpack the MAC, IV, and ciphertext from the packed message.
3. Verify the authentication tag by recalculating the HMAC of the IV/nonce and ciphertext with the user-provided HMAC by using hash_equals().
4. If and only if step 3 passes, decrypt the ciphertext using $eKey.

1. 按照加密中的第 2 步拆分您的密钥。我们在解密过程中需要相同的两个密钥！
2. （可选地，解码并）从打包的消息中解包 MAC、IV 和密文。
3. 通过使用hash_equals().
4. 当且仅当第 3 步通过时，使用 解密密文$eKey。

If you want to see how this all looks together, see this answer which has sample code.

如果您想看看这一切如何组合在一起，请参阅此答案，其中包含示例代码。

If this sounds like too much work, use defuse/php-encryptionor zend-cryptand call it a day.

如果这听起来工作量太大，请使用defuse/php-encryption或zend-crypt并收工。

---

---

Remember Me Cookies

记住我饼干

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。如果客户端提供此 cookie，则允许他或她以（几乎）相同的权限访问系统，就好像他/她提供了有效的用户名密码组合一样。

Encryption is actually not the correct tool for this job. You want to follow this process for secure remember me cookies in PHP:

加密实际上不是这项工作的正确工具。您希望遵循此过程以在 PHP 中安全记住我的 cookie：

Generating a Remember Me Token

生成记住我令牌

1. Generate two random strings:
   1. A selectorwhich will be used for database lookups. (The purpose of a random selector instead of just a sequential ID is to notleak how many active users are on your website. If you're comfortable leaking this information, feel free to just use a sequential ID.)
   2. A validatorwhich will be used to authenticate the user automatically.
2. Calculate a hash of validator(a simple SHA-256 hash will suffice).
3. Store the selectorand the hash of the validatorin a database table reserved for automatic logins.
4. Store the selectorand validatorin a cookie on the client.

1. 生成两个随机字符串：
   1. selector将用于数据库查找的A。（使用随机选择器而不仅仅是顺序 ID 的目的是不泄露您网站上有多少活跃用户。如果您愿意泄露此信息，请随意使用顺序 ID。）
   2. validator将用于自动验证用户身份的A。
2. 计算一个散列validator（一个简单的 SHA-256 散列就足够了）。
3. 将selector和 的散列存储在validator为自动登录保留的数据库表中。
4. 将selector和存储validator在客户端的 cookie 中。

Redeeming a Remember Me Token

兑换记住我令牌

1. Split the incoming cookie into the selectorand validator.
2. Perform a database lookup (use prepared statements!) based on selector.
3. If a row is found, calculate a hash of the validator.
4. Compare the hash calculated in step 3 with the hash stored in the database, once again using hash_equals().
5. If step 4 returns true, log the user in to the appropriate account.

1. 将传入的 cookie 拆分为selector和validator。
2. 执行数据库查找（使用准备好的语句！）基于selector.
3. 如果找到一行，则计算validator.
4. 再次使用 将步骤 3 中计算的哈希值与存储在数据库中的哈希值进行比较hash_equals()。
5. 如果步骤 4 返回 true，则将用户登录到适当的帐户。

This is the strategy that Gatekeeperadopted for long-term user authentication and it is the most secure strategy proposed to date for satisfying this requirement.

这是Gatekeeper为长期用户身份验证所采用的策略，也是迄今为止为满足此要求而提出的最安全的策略。

回答by Paul Crowley

You can achieve what you want securely by using AES in EAX mode. The ciphertext will be larger than the plaintext; that's normal for secure encryption.

通过在 EAX 模式下使用 AES，您可以安全地实现您想要的。密文会比明文大；这对于安全加密来说是正常的。

The attacker will of course know the length of your plaintext from the ciphertext, but they shouldn't be able to determine anything else.

攻击者当然会从密文中知道明文的长度，但他们不应该能够确定其他任何内容。

Generate AES keys randomly.

随机生成 AES 密钥。

Be sure and use a fresh nonce for each encryption, and use the "associated data" field to ensure that a thing you encrypted for one purpose isn't presented as being for another (so things like the user name and cookie name could go in there)

确保每次加密都使用新的随机数，并使用“关联数据”字段来确保您为一个目的加密的内容不会显示为另一个目的（因此用户名和 cookie 名称之类的内容可以进入那里）

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

下面的反应推向：不要相信加密来实现安全。

More "if you're not an encryption expert you'll underestimate how easy it is to get wrong". For example, AFAICT no-one else in this thread has discussed chaining modes or message integrity, which covers two common beginner's mistakes.

更多“如果您不是加密专家，您就会低估出错的难易程度”。例如，AFAICT 在此线程中没有其他人讨论过链接模式或消息完整性，其中涵盖了两个常见的初学者错误。

回答by inazaruk

While both a very strong ones, AES is a standard.

虽然两者都是非常强大的，但 AES 是一个标准。

As for security of small chunks of data: the smaller - the better. The less encrypted data is exposed, the longer you can use the key. There is always a theoretical limit of how much data can be encrypted within one key of given algorithm without exposing system to risks.

至于小块数据的安全性：越小越好。公开的加密数据越少，您可以使用密钥的时间就越长。在不使系统面临风险的情况下，在给定算法的一个密钥内可以加密多少数据总是存在理论上的限制。

回答by kravietz

As pointed out a few times in previous comments, you mustapply integrity protectionto any ciphertext that you send out to the user and accept back. Otherwise the protected data can be modified, or the encryption key recovered.

正如在之前的评论中多次指出的那样，您必须对发送给用户并接受回的任何密文应用完整性保护。否则可以修改受保护的数据，或恢复加密密钥。

Especially the PHP world is full of bad examples that ignore this (see PHP cryptography - proceed with care) but this does apply to any language.

尤其是 PHP 世界充满了忽略这一点的坏例子（请参阅PHP 密码学 - 小心处理），但这确实适用于任何语言。

One of few good examples I've seen is PHP-CryptLibwhich uses combined encryption-authentication mode to do the job. For Python pyOCBoffers similar functionality.

我见过的几个很好的例子之一是PHP-CryptLib，它使用组合加密-身份验证模式来完成这项工作。对于 Python pyOCB提供了类似的功能。

回答by Jonas K?lker

Why do you want to encrypt the cookie?

为什么要加密cookie？

As I see it, there are two cases: either you give the client the key, or you don't.

在我看来，有两种情况：要么你给客户钥匙，要么你不给。

If you don't give the key to the client, then why are you giving them the data? Unless you're playing some weird game with breaking weak encryption (which you're explicitly not), you might as well store the data on the server.

如果你不把钥匙给客户，那你为什么要给他们数据？除非您正在玩一些破坏弱加密的奇怪游戏（您明确没有这样做），否则您最好将数据存储在服务器上。

If you dohand the client the key, then why do you encrypt it in the first place? If you don't encrypt the communication of the key, then encrypting the cookie is moot: a MITM can look at the cookie and send you any cookie he wants. If you use an encrypted channel to the client, why the extra overhead of encrypting the stored data?

如果您确实将密钥交给了客户端，那么首先为什么要对其进行加密？如果您不加密密钥的通信，那么加密 cookie 就没有实际意义：MITM 可以查看 cookie 并向您发送他想要的任何 cookie。如果您使用加密通道到客户端，为什么加密存储数据的额外开销？

If you're worried about other users on the client's machine reading the cookie, give up and assume the browser sets good permission bits :)

如果您担心客户端机器上的其他用户读取 cookie，请放弃并假设浏览器设置了良好的权限位 :)

回答by mike

If you encrypt the cookie, the server still has to decode it to read it (to check for same key), therefore any encrypted cookie is pointless, because if stolen (and un-edited) it will still lead the hacker right to your account. Its just as unsafe as no encrypted at all.

如果您对 cookie 进行加密，服务器仍然需要对其进行解码以读取它（以检查相同的密钥），因此任何加密的 cookie 都是毫无意义的，因为如果被盗（和未编辑），它仍然会导致黑客访问您的帐户. 它就像根本没有加密一样不安全。

I believe the real issue of someone stealing your cookie is the connection between the server and client. Use SSL connection provided by your host.

我相信有人窃取您的 cookie 的真正问题是服务器和客户端之间的连接。使用您的主机提供的 SSL 连接。

As for your cookie, you need to make a long random id per user in the database, (have it change every log on) and just set that as the cookie or session. The cookie that contains the key can be checked via php and if it is equal to an account or table in your database, dump the data on the web page like normal.

至于您的 cookie，您需要在数据库中为每个用户创建一个长随机 id，（让它更改每次登录）并将其设置为 cookie 或会话。包含密钥的 cookie 可以通过 php 进行检查，如果它等于数据库中的帐户或表，则像往常一样将数据转储到网页上。

回答by Feha

I think that "giving away" any data even encrypted when it is about username and password is not good ... There are many JS that can sniff it ... I suggest you create in users DB table a field cookie_auth or whatever ...

我认为“泄露”任何关于用户名和密码的数据甚至加密都不好......有很多JS可以嗅探它......我建议你在用户数据库表中创建一个字段cookie_auth或其他...... .

after first login gather : current: browser, IP,ans some own salt key, plus your hostname var ...

首次登录后收集：当前：浏览器，IP，一些自己的盐密钥，加上您的主机名var ...

create a hash and store in that field ... set a cookie ... when cookie "responds" compare all of these with the stored hash and done ...

创建一个散列并存储在该字段中......设置一个cookie......当cookie“响应”时将所有这些与存储的散列进行比较并完成......

even if someone "steal" a cookie they won't be able to use it :-)

即使有人“偷”了一个 cookie，他们也无法使用它 :-)

Hope this helps :-)

希望这可以帮助 ：-）

feha vision.to

feha vision.to