我们最近为我们的 Web 应用程序开发了一些功能，以允许用户无限期地保持登录状态，并且有兴趣了解这样做的安全后果。这样做的目的是防止用户在编辑页面的时间过长时丢失数据 - 以前，一旦会话过期，他们就必须复制/粘贴到剪贴板，因为 POST 将被阻止并且登录是在不同的屏幕上处理的.

因此，我们现在检测用户会话是否接近到期，然后向他们展示一个允许他们单击按钮以保持会话活动的模式。如果他们长时间忽略此警告模式，我们会在他们的会话实际到期后立即将其替换为“重新登录”模式。

第一个模式/警告机制通过 AJAX get 调用服务器运行，该服务器返回注销前的时间。如果时间少于 15 分钟，我们打开“让我登录”模式，它有两个选项 - 立即注销或保持登录状态。显而易见，保持登录状态需要另一个 AJAX 再次访问服务器，这刷新用户的身份验证 cookie。

第二种模式更复杂 - 模式阻止与页面的进一步交互，并且只有在正确的密码重新输入时才会被删除。我们知道模态不会真正保护从页面读取数据，但这是需求的本质。

用户重新登录所需的数据（例如用户名和以前的角色）以纯文本形式存储在模式内的隐藏输入字段中。我们考虑过对此进行散列处理，但似乎并没有必要——用户名不是特别重要，并且在重新登录时会重新评估请求的角色；如果您尝试“调整”POST，则无法将自己升级为无权访问的角色。

我们考虑过的最坏情况是有人使用不同但有效的用户名/密码编辑 POST 并以其他人身份登录，同时仍留在页面上。他们将能够阅读该页面，但无论如何他们都可以这样做 - 导航离开将使他们返回到“新”登录的正确屏幕。我们可能需要做一些工作来确保在这种情况下所有 POST 都被阻止，但还有什么需要考虑的吗？通过再次手动输入用户名来强制用户重新识别有什么好处吗？

Web 应用程序是 ASP.NET MVC3。

更新

感谢您迄今为止的反馈。

我们已经接受了不信任来自客户端的数据，因此我们决定将用户名和角色一起加密，然后在登录尝试时解密。从那以后我们发现，由于我们已经实施了 AntiForgeryToken 保护措施，如果其他用户要登录，那么任何发布操作都将无法通过验证。

我们认为弹出窗口不会出现重大的可用性问题，因为超时当前设置为 60 分钟，并带有 15 分钟的警告。我们已经考虑到滑动过期直到中途才更新（http://msdn.microsoft.com/en-us/library/system.web.configuration.formsauthenticationconfiguration.slidingexpiration.aspx）。重要的是要记住，这一切都是为了解决用户对丢失数据的抱怨——他们在我们的系统上输入了大量的文本，这可能很耗时，并且会话在完成之前很有可能会过时。

稍后要添加的另一个功能是处理用户更改输入字段并向服务器发送心跳（除非它们已经未经身份验证）。我们还没有决定如何处理这个事件或触发心跳，以便它不会触发每次按键。一旦这到位，超时警告对话框的显示频率应该会降低。

可能值得一提的是整个站点都是 HTTPS，我们使用 ASP.Net AntiForgeryToken，它们是标记为安全的 HttpOnly Cookie。

如果有人有任何进一步的反馈或建议，很高兴收到您的来信。