使用cookie记住经过身份验证的用户

Question

在过去，我编写了一个CMS，其中通过两个cookie在HTTP请求中记住经过身份验证的用户：

• 用户令牌 - 一个随机的多字符（例如 10 - 数字长）字母数字字符串，它与数据库中的实际用户ID相关。

• 身份验证令牌 - 一个随机的多字符（例如 100 - 数字长）字母数字字符串，曾经哈希，必须与数据库中所述用户ID的存储值匹配。

我的问题（对于新的CMS）如下：

使用两个Cookie有什么意义？如果我改为使用单个 110 - 数字长令牌，而曾经哈希，则必须与某些的存储值匹配，这不是那么安全吗？ strong>数据库中的用户ID。当在数据库中找到此令牌的匹配项时，相关的用户ID将被视为经过身份验证的用户。

Answer 1

用户和身份验证令牌与组合令牌

将它们分开的最佳理由是让您的代码更易于管理，可移植，并与其他人一起玩。

安全

如果安全性是您唯一关心的问题，那么将用户和身份验证令牌组合成单个加密令牌会更安全，当且仅当两个序列都是通过不会导致任何特定字符更多的方法生成的重量很大。原因在于组合这两个值的行为本质上是一个额外的简单加密步骤，同时也是一个更大的加密密钥，因此更难以欺骗或破解。

角色的重量是指它发生的可能性。许多哈希或加密数据的方法很容易破解（Excel's horribly insecure password for one）。主要原因是由于某些字符更容易出现，因此许多字符也可以替代其他字符。最终的加密结果包含数十万个非预期和未知的加密密钥。 （尝试使用excel cracker作为例子）

可维护性和性能

但是，将两个值组合起来存在一些缺点，主要是性能和可维护性相关。

• 每次创建或收集组合密钥至少需要2个额外步骤。
• 任何需要获取或设置任何值都需要提取所有信息。
• 您可能不再更新auth-token，也不会更新用户令牌。
  • 如果您希望将用户与其他会话联系起来，这可能会在以后导致严重问题。即：google登录与您的身份验证系统配对。
• 如果他们打算添加任何功能，例如组级权限，则任何查看代码的人都必须对您创建user-auth组合的方式进行逆向工程。

已经符合

我自己并不是一个顺从者。然而，在许多事情中，人群将流向阻力最小的道路。通常情况下，只有在经验表明其他方式存在更大问题之后，常见做法才会变得普遍。这是其中一个案例。

最小的安全影响加上需要一个cookie而不是两个，用于便携性较差且性能较差的平台。在一天结束时，这是你的电话。

最后

• 最好不要再保留两个键，而只需要一个唯一的会话哈希。然后，只需将旧会话与用户配对，IFF会在到期后重新进行身份验证。
• 切勿使用Cookie（甚至加密）进行自动登录，而无需使用其他多项检查和平衡。即使有额外的支票，如果您要存储机密信息（姓名，地址，电话，电子邮件），您和您的用户之间的安全性也是如此，所以要格外小心。
• 在一天结束时，您就是建筑师，选择最适合您平台和环境的路线。