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.


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.


2 Answers 2


I smell two "bad smells" in this approach:

  • First, you should never trust the client. Storing the username on the client-side and then trusting the client to send it back honestly does not strike me as wise. You've already discovered that this could allow someone to access a single page under a different username. That already sounds a bit dubious, and how do you know there aren't worse attacks? I would recommend against any scheme that involves trusting, even if only for a little while, the client.

  • Second, the usability of this sounds problematic. Popping up dialog boxes that interrupt your flow is really annoying. Either cut off their session, or don't. Personally, for most websites I think there is not a great deal of danger in keeping their session open for a long time, if they've left a tab open, and I think the usability benefits of not forcing users to re-login are worth the security risks but that's for you to decide. My only suggestion is to avoid pop-up dialog boxes that interrupt your flow. Of course, I'm not an expert on usability. If you want a more expert opinion, you can ask on User Experience.SE.

    Update (11/14): I understand that you added the dialog box for a reason, but I still think it's probably not the best solution from a usability perspective. If the solution is that users who were in the middle of data entry were losing data, then there are other solutions that seem like they have better usability. Example: you can use Javascript to have the web application auto-save the text they've entered every 30 seconds, so that if their session times out on them, they can log back in and their text re-appears. Or, you could extend the length of the session. Or, you can detect user activity on any tab (typing, etc.), and only expire the session after 60 minutes of user inactivity. Asking User Experience folks might lead to other suggestions as well. I realize this is off-topic for this site, so I'll leave it at that.

I don't immediately have an attack that breaks your scheme and shreds it to ribbons. But these "bad smells" leave me with some concern and make me think that you haven't followed good practices for defensive design in web applications.

  • Thank you for your response. We have taken onboard your comment and have encrypted the username to help prevent tampering. The original post has been updated to reflect this.
    – user15895
    Nov 14, 2012 at 9:45
  • 2
    @user15895, glad it was helpful. Encryption doesn't sound like quite the right tool for this. In general encryption does not prevent tampering (that's a common misconception). Encryption is for confidentiality. If you want to prevent tampering, you want to protect authenticity -- so use a message authentication code, not encryption.
    – D.W.
    Nov 14, 2012 at 14:35
  • Keeping user session alive safe. As far as load, that's up to your hardware and how you write it, but it has no worse effect than users refreshing the page (arguably less considering the overhead of an AJAX call over a standard page load).
  • You can adjust the timeout in the web.config if that's what you're asking...
  • Cookies have their purpose, and I find them acceptable as long as it's your domain, but do realize some people disable them and so it comes down to having a fall-back.
  • There are server side postbacks when using .NET AJAX with UpdatePanel. The only difference is that the entire page is not loaded. All the server side code is triggered as normal, but the information is sent between the server and the page in a different way using the AJAX technology.
  • You can even call server side methods from client side javascript using a mechanism that .NET calls PageMethods. This is a more "manual" way of using AJAX in .NET than the traditional UpdatePanel technique.
  • Banks use the same methodology to keep your session going while you're checking your finances, but usually offer a popup just before to ask if you'd like to continue.
  • Keeping a user forcefully logged in for longer than a normal duration can be a security risk (picture someone logging in at a library or school computer and leaving their desk--should that session continue on in to the next day

The following resources may help you

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .