We have recently developed some functionality for our web app to allow a user to remain logged in indefinitely, and are interested in knowing the security ramifications of doing so. The goal of this was to prevent user data loss if they take an excessively long time to edit a page - previously they'd have to copy/paste to clipboard once the session expired as POSTs would be blocked and logon was handled on a different screen.
So, we now detect if a user session is close to expiry and then present them with a modal that allows them to click a button to keep their session alive. If they ignore this warning modal for long enough, we replace it with a "log back in" modal as soon as their session actually expires.
The first modal/warning mechanism operates via an AJAX get call to the server which returns the time until logout. If the time is less than 15minutes we open the "Keep me logged in" modal which has two options - log me out now or stay logged in. Log me out does the obvious, staying logged in entails another AJAX get to the server again which refreshes the user's auth cookies.
The second modal is more complicated - the modal blocks further interaction with the page and is only removed upon correct password re-entry. We are aware that a modal won't really protect reading data from the page but this is the nature of the requirement.
Data required for the user to re-logon (such as username and previous role) is stored in plain text in hidden input fields within the modal. We considered hashing this but it didn't really seem to be necessary - username isn't particularly critical and the requested role is re-evaluated at re-logon; you can't upgrade yourself to a role you don't have access to if you tried to 'adjust' the POST.
The worst case scenario we have considered is that someone edits the POST with a different yet valid username/password and logs in as someone else whilst remaining on the page. They would be able to read the page but they can do that anyway - navigating away will return them to the correct screens for the 'new' login. We probably need some work done to ensure all POSTs are blocked in this scenario but is there anything else to consider? Is there anything to be gained from forcing the user to re-identify by manually typing their username again?
The web app is ASP.NET MVC3.
UPDATE
Thanks for the feedback so far.
We've taken onboard not trusting data from the client so we have decided to encrypt the username and role together and then we decrypt this on the login attempt. We have since discovered that due to the AntiForgeryToken safeguards that we already have in place if a different user was to login then any post actions would fail validation.
We don’t feel that there will be a major usability issue with the popup as the timeout is currently set to 60 minutes with a 15 minute warning. We have already factored in the sliding expiration not updating until after half way (http://msdn.microsoft.com/en-us/library/system.web.configuration.formsauthenticationconfiguration.slidingexpiration.aspx). It is important to remember this was all implemented to address user complaints about losing data - they enter a large amount of text on our system which can be time consuming and has a high chance of the session going stale before they are finished.
Another feature to be added at a later time would be to handle a user changing input fields and sending a heartbeat to the server (unless they are already un-authenticated). We have not yet decided how to handle this event or to trigger the heartbeat so that it does not fire every keypress. Once this is in place the timeout warning dialog box should show less often.
Something else that might be worth mentioning is that the entire site is HTTPS and we use ASP.Net AntiForgeryToken which are HttpOnly Cookies flagged as secure.
If anyone has any further feedback or suggestions it would be great to hear from you.
