我计划使用用户 AES256 以确保客户端无法更改 cookie 的值。

加密提供机密性，但不提供身份验证。

如果您不希望用户看到会话数据值，那么您应该加密然后验证该值。这可以防止位翻转攻击更改加密令牌内部的值，因为如果任何位被交换，键控哈希将不再匹配。

如果不需要保密，那么您可以简单地进行身份验证。例如，您可以在 SHA-256 上使用 HMAC。这将以明文形式向最终用户显示该值是什么，但是他们将无法更改该值，因为他们将无法在没有密钥的情况下重新计算键控哈希值。

例如，您的 cookie 将设置如下：

Set-Cookie: Session=Username=admin&expires=20150809104100&hash=7C2CD7DB7DF4055E782E3A5F70487FEB9A5CABEED3FB70F5D8772586FD8B2759

Expires 防止用户在不是管理员时离线保存 cookie 以供以后使用，因为哈希也是在过期时间计算的：

Username=admin&expires=20150809104100

您可以使用此站点来验证这一点（使用的密钥是stackexchange，但是您应该使用加密安全的伪随机生成的 128 位密钥）。

但是，有一种已称为JSON Web Tokens的互联网标准技术可以做到这一点。HS256 算法将生成由 HMAC 在 SHA-256 上计算的客户端令牌值。

如果您还想要加密，请选择A128GCM- 请注意，128 位密钥足以存储您的数据 - 使用 AES-256 的 256 位密钥速度较慢且不必要。它甚至可能不太安全，因为 AES 处理 128 位和 256 位密钥的方式存在显着差异。

由于 JSON Web Encryption 仅支持经过身份验证的加密算法，这也将防止位翻转。

仅加密是不够的，因为它只提供机密性，而且这项任务还需要真实性。

如果攻击者 cookie 中的明文包含类似用户编号 9 已通过身份验证的内容，那么攻击者可以更改密文中的位，当在服务器上对其进行解密时，它会显示用户编号 1 已通过身份验证并作为用户编号 1 进行身份验证。这是通过逐步更改 cookie 密文中的位并将其发送到服务器来完成。

为防止此类篡改，您需要实施经过身份验证的加密，以检测（在服务器上）密文（在客户端）中不需要的更改。