18 ms·

I'm not going to speak for the company or their solution, but yes it is a serious problem. The token itself isn't the hard part as you pointed out, it's the fu

I'm not going to speak for the company or their solution, but yes it is a serious problem. The token itself isn't the hard part as you pointed out, it's the full life cycle management of it and the security analysis is. Detecting and acting on session hijacking is hard to do right. It can get very complicated as well if your system needs to enforce things like non-concurrent logins, etc. But I'm glad the company offers a self-hosted version rather than being forced to rely on their managed service (that was the first thing I looked at). I haven't dug into it at all and am taking at face value that their self-hosted daemon doesn't have any required real-time connections to their systems, but that would be a deal killer as well.

rishabhpoddar 6y ago
Thank you!! We use rotating refresh tokens to detect session theft reliably.
- md_ 6y ago
  I'm not entirely sure I'm understanding the terminology you're using. Are you talking about OAuth2 tokens (i.e. https://tools.ietf.org/html/rfc6819#section-5.2.2.3 https://tools.ietf.org/html/rfc6819#section-5.2.2.3), or are you talking about browser cookies? In both cases, rotation strikes me as being of limited (though nonzero) value. While rotation (and invalidation of the previous token) can be used to prevent long-lived concurrent use of cloned tokens, there's a good chance an attacker can ensure that they are the ones who get the "new" token. As a result, the user--the legitimate OAuth client or browser--would be left with the now-invalidated token, and will be logged out. The most likely result of which--depending on application design choices--is that the user simply logs in again! You now have two sessions, one of which is solely owned by an attacker, and one of which is solely owned by a user! (There are cases where this is still valuable: if you enforce "only one session globally" per user, for example, or if you use the presentation of an "invalidated" token as indicative of theft. But both are application design choices that will commonly be inappropriate.) At the extreme, of course, if your threat model is local malware, UXSS, etc, an attacker can just do a "person in the browser" attack, in which no token copying happens. I'm not sure why I'm bothering to write all of this. Call it free consulting? ;) My point is really that the threat model needs to be clearly stated and, for some threat models (including some which are featured in case studies on your website), this approach may be largely ineffective.

rishabhpoddar 6y ago

Thank you!! We use rotating refresh tokens to detect session theft reliably.

md_ 6y ago
I'm not entirely sure I'm understanding the terminology you're using. Are you talking about OAuth2 tokens (i.e. https://tools.ietf.org/html/rfc6819#section-5.2.2.3 https://tools.ietf.org/html/rfc6819#section-5.2.2.3), or are you talking about browser cookies? In both cases, rotation strikes me as being of limited (though nonzero) value. While rotation (and invalidation of the previous token) can be used to prevent long-lived concurrent use of cloned tokens, there's a good chance an attacker can ensure that they are the ones who get the "new" token. As a result, the user--the legitimate OAuth client or browser--would be left with the now-invalidated token, and will be logged out. The most likely result of which--depending on application design choices--is that the user simply logs in again! You now have two sessions, one of which is solely owned by an attacker, and one of which is solely owned by a user! (There are cases where this is still valuable: if you enforce "only one session globally" per user, for example, or if you use the presentation of an "invalidated" token as indicative of theft. But both are application design choices that will commonly be inappropriate.) At the extreme, of course, if your threat model is local malware, UXSS, etc, an attacker can just do a "person in the browser" attack, in which no token copying happens. I'm not sure why I'm bothering to write all of this. Call it free consulting? ;) My point is really that the threat model needs to be clearly stated and, for some threat models (including some which are featured in case studies on your website), this approach may be largely ineffective.