Often when an account is hacked, security guidance is to change your password. However I've noticed that changing a password sometimes isn't enough to log out of other sessions that are active.

  • Is there any accepted security guidance that recommends or requires that all logon sessions are expired and must be re-authenticated? This could be industry specific, or from a respected government or private company that publishes similar guidance.

I found an interesting approach in practice, where Facebook gives the user the option to disconnect all sessions

enter image description here

  • Your password is used when you authenticate only. Cookies take it from threre. Changing your password does not change your cookies. You can clear your cookies, but the attacker who logged in with your old password won't :) – ixe013 Nov 28 '12 at 16:18
  • 1
    @ixe013 I updated the question to only focus on "formal guidance". However, it is technically possible for the server to invalidate other sessions and issue a new session token. – goodguys_activate Nov 28 '12 at 16:29
  • I don't know about a formal guidance, but a server could add a something like a version, like a counter or a timestamp, to the authentication cookie. So when a request comes in, the server would : 1. Decrypt the cookie or verify that it was not tampered with 1. Read the password version or timestamp that was valid when the cookie was generated 1. If the password version or timestamp is older, prompt for authentication again. This might be harder to do in other environments. For example, a Kerberos ticket held by an attacker will stay valid after you reset your password. On the web, GMail has t – ixe013 Nov 28 '12 at 17:36
  • 1
    @ixe013 You're assuming a lot about the OP's environment that isn't necessarily true. He might not be using cookie's to store session state. He might not even be talking about HTTP at all. – Mark E. Haase Nov 29 '12 at 5:00
  • Very true, @mehaase. I have updated my answer below to mention its limits. – ixe013 Nov 29 '12 at 14:08

OWASP cover this in the top 10 (2010) under "Broken Authentication and Session Management". The closest statement probably is that it mentions that sessions should be regenerated upon successful authentication of privilege change coupled with Session Timeout session fixation attack prevention. That's about as close to a standard as you will get.

Other standards such as ISF SOGP etc are too high level to cover this.

  • This prevents an attacker from getting a valid session cookie, maybe by starting a registration process, and forcing you to authenticate using that session cookie. The attacker does not have the password, but is valid session cookie is now authenticated. Asking the old password when you change your original password prevents further damages. – ixe013 Nov 28 '12 at 17:39
  • it's certainly worth taking this particular use case to OWASP and get them to include it in their top 10 notes. – Callum Wilson Nov 29 '12 at 12:40

There is no single piece of advice because various applications have different requirements.

Credentials are most often handled in the form of tokens. You authenticate yourself to a server, it returns a token, you cache the token and pass it to each system you're dealing with. The token could be of any form: a cookie, a session ID, a Kerberos ticket, an NTLM token, or whatever. The client stores it in a local cache, and presents it every time it uses a service that needs to know your credentials.

So the next thing you (as a client) want to do is to access some service. You present the token, the service calls the authenticating server, figures out your groups/roles/authority, learns the expiration time of your token, and grants you access. The service then simply caches your token and all those attributes, then compares every incoming request to see if you're still using the same token. It doesn't re-validate your token until the expiration time indicated by the authenticating server.

In a service intensive app, you would have performance problems if you asked the authenticating server to authenticate every single service request. (Consider that a typical Windows app might present the security token to a dozen different Win32 API calls before even showing you the "welcome" screen!) Therefore, for those systems caching the token at the service level is critical.

But as long as the cached copy is used, it's not being re-checked to see if it's been subsequently invalidated. You might sign on to Facebook in a panic because you remembered you left yourself logged in at the coffee shop and set the flag, but you'll have to wait for the next cache expiration before it takes effect.

In a high security application, you may turn the expiration time way down. I suppose it's possible that you could require that your services perform no caching of credential attributes, and that all tokens are always sent to the authenticating server. In a low security application (perhaps a blog) you would probably place more value on convenience and performance.

From your description, it sounds like Facebook probably has custom integration between their session management and their credential systems. If you tick the "log me out" button, it may post a notification to the session management system to immediately invalidate all sessions associated with your account. Which would be clever and hyper-fast, but I don't think most authenticating systems support pub/sub notifications like that. I am unaware of any such callback service offered by Kerberos, but I think the next version of Apache Directory Services is going to offer "triggers", which sound like they might be used for the same purpose.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.