AES256密码和iv，正确的做法
AES256 password and iv, the right way
我想使用 AES256 加密令牌创建和管理用户会话。
我正在使用节点的加密库并遵循此 Whosebug question。
我正在使用它来创建会话令牌，该令牌将被发送到前端并存储在后端以进行验证，并且数据被字符串化 JSON。
在这里我看到两件事，一个是 password，另一个是 iv。
所以两个问题，
发送到前端的 iv 是否安全(iv + "." + encData)？
密码应该如何生成？ SHA256 怎么样（例如，我在注册时存储在数据库中的用户密码）
这样我将为每个用户使用不同的密码。这种做法正确吗？
P.S。下面的两个答案都有很大帮助，如果你在这里，请阅读所有评论和附加的问题以及链接的文章。
您可能想要 AES 加密，但加密并不是您需要的！为了您的应用程序的安全，消息完整性比加密更重要。
加密通常不提供消息完整性（请参阅 Top 10 Developer Crypto Mistakes 的第 7 节），除非您专门使用提供它的操作模式（例如 GCM 模式）。因此，您设计的解决方案本质上是错误的。更多信息在下面的脚注 (!) 中。
了解您的需求 -- 消息完整性 + 加密，或仅消息完整性。如果仅是消息完整性，则使用 HMAC。
您需要了解的另一件事是，AES 和 HMAC 等函数不使用密码，而是使用加密密钥。请参阅 Top 10 Developer Crypto Mistakes 的第 6 节。
目前尚不清楚你关于 IV 的问题是否重要，因为你的方法是错误的，但无论如何要回答它，IV 不需要保密。请参阅 10 大开发人员加密错误的第 2 部分。
我大体上同意上面的评论：按照应有的方式使用 JWT，而不是尝试构建您自己的解决方案。 JWT 已为 expiration 保留声明，因此没有理由不这样做。
脚注 (!)：如果您想了解消息完整性和加密之间的混淆是如何被滥用的，您可以尝试来自 Pentester Labs 的 this exercise（不幸的是它需要订阅，但它很便宜）。当然，这是针对 ECB 模式的，类似的概念也适用于 CBC 模式。
让我们继续手头的问题：
- Is the iv is safe to sent to frontend (iv + "." + encData)?
嗯，是的。 IV 可能是 public 知识；只要它是唯一的，并且在 CBC 模式加密的情况下是随机的，那么就可以了。当然，应该对 IV 和 encData 进行适当编码，例如使用十六进制（如链接答案中所示）或 base 64。这并不经常这样做，因为 AES 的 IV 始终为 16 个字节，因此很容易简单地在二进制 IV 改为 encData。
谨防黑客更改输入；如果删除了点或冒号，那么您可能只有一个元素的数组，并且访问密文可能会导致错误或空数据的解密。
- How should the password be generated? How about a SHA256 of (e.g. user's password that I store in db at signup)
不，您应该为此使用密码哈希； SHA-256 是一种加密安全散列，但不是密码散列，例如 PBKDF2、bcrypt、scrypt 或 Argon2。如果你想在数据库中存储一些东西，那么请不要让它成为从密码生成的 AES 密钥。
这不会以任何方式使 中的任何担忧无效。这不是安全建议，只是您要求的与密码学相关的建议。
我想使用 AES256 加密令牌创建和管理用户会话。
我正在使用节点的加密库并遵循此 Whosebug question。
我正在使用它来创建会话令牌，该令牌将被发送到前端并存储在后端以进行验证，并且数据被字符串化 JSON。
在这里我看到两件事，一个是 password，另一个是 iv。
所以两个问题，
发送到前端的 iv 是否安全
(iv + "." + encData)？密码应该如何生成？ SHA256 怎么样（例如，我在注册时存储在数据库中的用户密码）
这样我将为每个用户使用不同的密码。这种做法正确吗？
P.S。下面的两个答案都有很大帮助，如果你在这里，请阅读所有评论和附加的问题以及链接的文章。
您可能想要 AES 加密，但加密并不是您需要的！为了您的应用程序的安全，消息完整性比加密更重要。
加密通常不提供消息完整性（请参阅 Top 10 Developer Crypto Mistakes 的第 7 节），除非您专门使用提供它的操作模式（例如 GCM 模式）。因此，您设计的解决方案本质上是错误的。更多信息在下面的脚注 (!) 中。
了解您的需求 -- 消息完整性 + 加密，或仅消息完整性。如果仅是消息完整性，则使用 HMAC。
您需要了解的另一件事是，AES 和 HMAC 等函数不使用密码，而是使用加密密钥。请参阅 Top 10 Developer Crypto Mistakes 的第 6 节。
目前尚不清楚你关于 IV 的问题是否重要，因为你的方法是错误的，但无论如何要回答它，IV 不需要保密。请参阅 10 大开发人员加密错误的第 2 部分。
我大体上同意上面的评论：按照应有的方式使用 JWT，而不是尝试构建您自己的解决方案。 JWT 已为 expiration 保留声明，因此没有理由不这样做。
脚注 (!)：如果您想了解消息完整性和加密之间的混淆是如何被滥用的，您可以尝试来自 Pentester Labs 的 this exercise（不幸的是它需要订阅，但它很便宜）。当然，这是针对 ECB 模式的，类似的概念也适用于 CBC 模式。
让我们继续手头的问题：
- Is the iv is safe to sent to frontend (iv + "." + encData)?
嗯，是的。 IV 可能是 public 知识；只要它是唯一的，并且在 CBC 模式加密的情况下是随机的，那么就可以了。当然，应该对 IV 和 encData 进行适当编码，例如使用十六进制（如链接答案中所示）或 base 64。这并不经常这样做，因为 AES 的 IV 始终为 16 个字节，因此很容易简单地在二进制 IV 改为 encData。
谨防黑客更改输入；如果删除了点或冒号，那么您可能只有一个元素的数组，并且访问密文可能会导致错误或空数据的解密。
- How should the password be generated? How about a SHA256 of (e.g. user's password that I store in db at signup)
不，您应该为此使用密码哈希； SHA-256 是一种加密安全散列，但不是密码散列，例如 PBKDF2、bcrypt、scrypt 或 Argon2。如果你想在数据库中存储一些东西，那么请不要让它成为从密码生成的 AES 密钥。
这不会以任何方式使