安全Cookie策略

Question

在阅读了如何确保“记住我”令牌安全并阅读psecio的Gatekeeper PHP库的源代码之后，我已经提出了以下保持安全的策略，我想知道是否这将是非常错误的。我基本上做了以下事情：

1. 当用户登录时，使用系统的随机数生成器生成加密安全字符串。 （Python中的random.SystemRandom（））这是通过从所有小写和大写ASCII字母和数字的选择中选择随机字符来生成的。 （''.join(_random_gen.choice(_random_chars) for i in range(length))，根据Django的相同方式。_random_gen是安全随机数生成器）
2. 生成的令牌与其随附的用户ID以及未来1分钟的到期时间一起插入RethinkDB数据库。然后使用RethinkDB生成的唯一ID来创建cookie值，以识别该条目和之前的sha256-hashed标记。基本上：':'.join(unique_id, sha256_crypt.encrypt(token))。 sha256_crypt来自Python的passlib库。
3. 当用户访问要求他们登录的页面时，将使用存储的ID从数据库中检索实际的cookie值。然后使用sha256_crypt.verify
针对实际Cookie验证散列cookie
4. 如果验证通过并且先前存储的时间值小于当前时间，则会删除数据库中的上一个条目，并生成新的ID /令牌对以存储为cookie。

这是一个好策略，还是有一个我没有看到的明显缺陷？

编辑：重新阅读我在评论中链接的一些Stack Overflow帖子后，我更改了上面的过程，以便数据库存储哈希标记，并将实际标记作为cookie发回。 （当然，这只会在https上发生）

Answer 1

您应该确保在安全字符串中生成足够的字符。我的目标是64位熵，这意味着你的字符串中至少需要11个字符来防止任何类型的实际蛮力。

根据OWASP's recommendation for Session Identifiers：

  

对于一个非常大的网站，攻击者可能会尝试每次进行10,000次猜测   第二，有100,000个有效会话标识符可供猜测。   鉴于这些假设，攻击者的预期时间   成功猜测有效会话标识符大于292   年。

鉴于292年，每分钟产生一个新的似乎有点过分。也许你可以改变它来每天刷新一次。

我还会为你的哈希值存储值（称为胡椒）添加系统范围的盐。如果攻击者设法访问您的会话表，这将阻止任何预先计算的彩虹表提取原始会话值。创建一个16位加密安全随机值，用作胡椒。

除此之外，我没有看到你所描述的内在问题。通常的建议适用：还使用HSTS，TLS / SSL和安全cookie标记。