关于持久性登录的这种方法，我应该注意任何问题（“记住我”）？

Question

此Web应用程序将具有一个数据库表，其中包含uniqueid（64位int自动增量字段;键），令牌（64字节二进制字段）和accountid。

登录“记住我”后，将生成一个随机令牌。然后，将此令牌的SHA-512哈希值插入到数据库中，并检索生成的唯一ID。包含唯一ID和未散列令牌的cookie将发送到客户端。

每次用户使用cookie访问页面时，都会根据数据库检查cookie的uniqueid及其令牌的SHA-512哈希值。如果有一行与uniqueid匹配，并且该行的令牌哈希与令牌哈希匹配，请使用行的accountid登录用户。在cookie执行每次身份验证后，删除使用旧uniqueid的行，如果身份验证成功，则生成新的随机令牌。然后，将此令牌的SHA-512哈希值插入到数据库中，并检索生成的唯一ID。包含uniqueid和unhashed令牌的cookie将发送到成功通过身份验证的客户端。

我将使用here描述的技术。所有失败的cookie身份验证都会将Cookie设置为空值，并将过期日期设置为过去的某个时间。

我相信这种方法可以解决一些关于cookie的问题。即：

1. 对数据库中的令牌进行哈希处理，以便只要攻击者没有对数据库的写访问权限，他/她将无法伪造 所有用户。

2. 使用唯一ID代替用户的帐户名，因为登录 凭证永远不应存储在cookie中。

3. 每次验证cookie时都会生成一个随机令牌 因此，如果攻击者窃取了一个cookie，它只会在有效期之前有效 用户接下来登录而不是用户的整个时间 记住。

4. Cookie很难嗅探，因为我的整个应用程序都使用HTTPS。

我可以通过允许用户指定他/她想要记住的时间来进一步增强安全性。到期日期将存储在存储uniqueid和令牌的同一数据库表中。每次创建新cookie时，此过期都将随cookie一起发送。如果用户尝试使用服务器认为已过期但客户端仍然保留的cookie登录，则登录将被拒绝。

我相信这个解决方案相当安全，但是在我设计这种方法时，是否存在任何我忽略的陷阱或事情？

来源：

Hash token in database

Don't store account name in cookies and use new unique id after every authentication

Answer 1

说到安全性，合理的总是相对的。 :)如果你认为它适合你面临的威胁是合理的。也就是说，如果这是我的应用程序，我会做的一些事情，我相信我实际上需要保护它免受攻击......

• 将某些内容标记到令牌/ b / e中，允许您关联回原始身份验证事件，然后将其记录在所有Cookie操作中。这样你可以做关联，如果（当:)）人被黑客攻击你想弄清楚发生了什么。
• 在b / e上，请确保实施“使我所有未完成的令牌无效”作为系统的一项功能。然后自动将其连接到所有“可疑”事件。
• 将地理信息存储在cookie / b / e中，其中包含与cookie对应的行。首先记录它。最终你会想要做更多。当你研究被黑客攻击的人时，你会发现你可以用这些数据做更多的事情。如果您没有这些数据，则无法学习。
• 很多仪器。很多很多仪器。保留多年。一切都会得到一个事件，记录事件发生时你所知道的一切。良好的可视化/查找工具，您可以用它来弄清楚发生了什么。

当然，你可以做更多的事情，这只是一个入门名单......