2012-11-12

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.

Show more