我们刚刚让安全审计员标记了我们使用持久性 cookie 来维护 Web 应用程序中的登录状态。作为背景知识，我们的 Web 应用程序是多租户的，但没有（或不是很多）操作具有破坏性。根据租户的不同，我们的门户可能会提供敏感信息。
当我们设计我们的应用程序时，我们讨论了持久性 cookie 的使用，并决定我们应该基于可用性。我们没有，而且在某种程度上仍然没有，认为可用的信息是敏感的。我们的用户相当新手，我们更关心有数百个重置密码请求。
使用持久性 cookie 登录是否被视为安全风险？当我们谈论一些相当大的企业的运营数据时，可用性的权衡是否是一个讨论？
我们之前没有任何关于持久性 cookie 的问题——我们的任何客户都没有。是否值得实施一个默认为关闭以满足双方的“坚持不懈”？
持久性 cookie 用于多种原因，并支持多种功能。如果您的应用程序绝对没有“敏感”内容，那么您可以使用持久性 cookie 进行永久身份验证，然后发出重新身份验证以访问用户帐户详细信息，或进行一些更改（即更改密码或电子邮件地址）。您提到您的用户是新手，所以我认为他们不知道如果其他人使用他们的浏览器，他们也会在不知道他或她的密码的情况下进行身份验证（我会向用户指出）。
但是有一个原因，为什么像网上银行这样的安全关键应用程序不会发出持久登录 cookie，尽管它们可以，因为在对您的帐户余额进行任何更改之前，您必须重新进行带外身份验证（通过移动设备或某种形式一次性密码）。但它被认为是不安全的，也许是因为知道某人的余额已经侵犯了他们的隐私。
因此，如果您的应用不受任何政府机构控制，并且您不受所在国家/地区的任何法律的约束，并且您对应用的敏感部分实施重新身份验证，那么发布 2-3 周的持久 cookie 进行身份验证，是不是重大的安全威胁。
如果不信任持久性 cookie，Fatfredyy 的建议听起来很棒。
但是，如果问题在于持久性 cookie 的使用不安全，为什么不加密它们呢？
在勾选“记住我”或默认情况下会生成一个 cookie，其中包括一些难以理解的用户唯一 ID 和包含验证的加密部分。对称加密的密钥与用户 ID 一起存储在数据库中，并且从不与用户共享。当用户重新访问时，您使用该 ID 访问密钥并解密其余部分，以验证没有被篡改。
当识别出尝试修改用户 ID 时，向用户显示一条消息并更改加密密钥，要求用户重新进行身份验证。
这将使您能够在不损害用户的情况下使用持久性 cookie。