5 ms·

Is this really a problem that needs solving? Generate a secret, hash it, and store it in your database. Set the secret as a cookie in the client. On every requ

Is this really a problem that needs solving? Generate a secret, hash it, and store it in your database. Set the secret as a cookie in the client. On every request, hash the cookie value on your server and compare it to your DB values. It seems like very little effort to implement this yourself in a way that doesn't involve completely trusting a different company.

rishabhpoddar 6y ago
We believe that session attacks are going to increase in the future given that login is becoming more secure (passwordless, hardware keys etc etc).. As such, for long lived sessions, just having one token makes that the weakest link in that user's security. That's why we believe that this is a problem worth solving = minimising security risk. The method you suggested is one that you understand and can build. A lot of developers do not know much about session security, but still want security. Thanks for your feedback though. It's true that not all apps will want this level of security. We understand that.
- eganist 6y ago
  > As such, for long lived sessions, just having one token makes that the weakest link in that user's security. That's why we believe that this is a problem worth solving = minimising security risk. Can you help me understand the specific attacks you're trying to mitigate that aren't already solved by a combination of best practices implemented by current engineering frameworks (session management across most fairly mature tech stacks) and browser controls (e.g. samesite cookies)?
  - malinens 6y ago
    for example, spammers and hackers use the same session id across different devices. this technique can help avoiding rate limits and also allow using it programmatically. it is nice to be able detect such things. I work for e-mail provider and spammers are becomming increasingly sophosticated and are finding new ways to exploit such security holes
  - rishabhpoddar 6y ago
    Thanks for your comment. There are a couple of points for this answer: -> Short lived sessions: A lot of the guidelines (OWASP, NIST, industry compliances) recommend having short inactivity timeouts, and "in session", frequent reauths. Those have clear UX problems, but for apps that are OK with those problems, implementing such mechanisms is good enough, security wise! Most existing libraries easily allow you to build inactive timeouts, but building the frequent "in session" reauth, can be tricky: detecting when last auth happened, saving state of an app between reauths & regenerating session tokens after reauth. Due to these issues, sites end up implementing sessions from scratch and mostly always make some mistake. For example, I have seen banks store session tokens in the page HTML as opposed to HttpOnly cookies. One of our aim is to make it very simple to implement all these best practices recommended by OWASP, NIST, and industry compliances. -> Long lived sessions: For all other apps that want to keep their users logged in for longer, frameworks only enable the use of one long lived session token (alive for weeks or months). In this case, if that token is compromised, the user's account is compromised for a long time. Theft of token is possible in multiple ways, even if using httpOnly cookies: https://supertokens.io/pdf/attackshomepagev2 https://supertokens.io/pdf/attackshomepagev2 For some people, this risk matters. For them, they want to achieve long lived sessions + reduce the risks of theft. For them, using the existing framework solution is not good enough. -> Functionality: There are a lot of functionality that can be required on top of sessions: - Syncing session data across devices - Getting all active sessions of a user - Setting different inactivity timeouts based on a user's role - Revoking access to a specific device - Logging in as a user (for support team) Most of these and perhaps more are required for "serious" apps. Most frameworks do not allow to easily implement all of the above. As result, devs implement their own session solution, and make mistakes. -> Other considerations: For many devs, JWT is the goto for sessions (free scalability). Since most frameworks do not choose JWTs for sessions (in their inbuilt solution), devs choose to use something else and make mistakes like storing the JWTs in localstorage. Incorrectly configuring sessions in these frameworks can also cause issues. For example, during development, secure attribute for cookies is usually set to false. Sometimes, devs forget to set them to true for production use. Another example is that during development, your API is on api.example.com, but your site is on localhost. For this to work, you set sameSite to none, and forget to switch it to lax for production. SuperTokens aims to be very opinionated in order to prevent such mistakes (...catching these errors is not yet implemented though, but soon). -> Conclusion: Overall, the in built sessions in the frameworks are good for many apps. However, for those "serious" or complex apps, people end up building something custom (and that's a lot of companies ~ 50% of our YC batch built a custom solution or used JWTs despite of inbuilt sessions in their framework). Our solution is for such people.
candiddevmike 6y ago
Additionally, OWASP publishes so many guides on session management, along with checklists, to make it easy to see state of the art and best practices in this domain.
- rishabhpoddar 6y ago
  They do! But most open source solutions to not follow them, which means most apps do not follow them, and for those who care about OWASP session guidelines, need to mostly build their own system.
jrexilius 6y ago
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.
tompic823 6y ago
> It seems like very little effort to implement this yourself in a way that doesn't involve completely trusting a different company. What about cookie configuration (secure, httpOnly, samesite), signing, expiration, session management, etc? Getting and setting the cookie value are the easy part. For someone entrenched in appsec, most of these are fairly easy. But most developers are not entrenched in appsec. For proof of this, look at the popularity of Auth0.
- rishabhpoddar 6y ago
  Thanks! And more proof for this comment is the sheer number of questions / blog posts written about sessions and JWTs almost weekly on reddit, HN, stackoverflow etc.. If this was very simple to solve, securely, those questions, blog posts would not exist.
PaulHoule 6y ago
I think the problem is that websites today don't have enough single points of failure or maybe that websites today have too few third parties with access to private information. Something like that. It reminds me of the fad to get people to use "Javascript CDNs" that are "free" because they track your users with cookies.

rishabhpoddar 6y ago

We believe that session attacks are going to increase in the future given that login is becoming more secure (passwordless, hardware keys etc etc).. As such, for long lived sessions, just having one token makes that the weakest link in that user's security. That's why we believe that this is a problem worth solving = minimising security risk. The method you suggested is one that you understand and can build. A lot of developers do not know much about session security, but still want security. Thanks for your feedback though. It's true that not all apps will want this level of security. We understand that.

eganist 6y ago
> As such, for long lived sessions, just having one token makes that the weakest link in that user's security. That's why we believe that this is a problem worth solving = minimising security risk. Can you help me understand the specific attacks you're trying to mitigate that aren't already solved by a combination of best practices implemented by current engineering frameworks (session management across most fairly mature tech stacks) and browser controls (e.g. samesite cookies)?
- malinens 6y ago
  for example, spammers and hackers use the same session id across different devices. this technique can help avoiding rate limits and also allow using it programmatically. it is nice to be able detect such things. I work for e-mail provider and spammers are becomming increasingly sophosticated and are finding new ways to exploit such security holes
- rishabhpoddar 6y ago
  Thanks for your comment. There are a couple of points for this answer: -> Short lived sessions: A lot of the guidelines (OWASP, NIST, industry compliances) recommend having short inactivity timeouts, and "in session", frequent reauths. Those have clear UX problems, but for apps that are OK with those problems, implementing such mechanisms is good enough, security wise! Most existing libraries easily allow you to build inactive timeouts, but building the frequent "in session" reauth, can be tricky: detecting when last auth happened, saving state of an app between reauths & regenerating session tokens after reauth. Due to these issues, sites end up implementing sessions from scratch and mostly always make some mistake. For example, I have seen banks store session tokens in the page HTML as opposed to HttpOnly cookies. One of our aim is to make it very simple to implement all these best practices recommended by OWASP, NIST, and industry compliances. -> Long lived sessions: For all other apps that want to keep their users logged in for longer, frameworks only enable the use of one long lived session token (alive for weeks or months). In this case, if that token is compromised, the user's account is compromised for a long time. Theft of token is possible in multiple ways, even if using httpOnly cookies: https://supertokens.io/pdf/attackshomepagev2 https://supertokens.io/pdf/attackshomepagev2 For some people, this risk matters. For them, they want to achieve long lived sessions + reduce the risks of theft. For them, using the existing framework solution is not good enough. -> Functionality: There are a lot of functionality that can be required on top of sessions: - Syncing session data across devices - Getting all active sessions of a user - Setting different inactivity timeouts based on a user's role - Revoking access to a specific device - Logging in as a user (for support team) Most of these and perhaps more are required for "serious" apps. Most frameworks do not allow to easily implement all of the above. As result, devs implement their own session solution, and make mistakes. -> Other considerations: For many devs, JWT is the goto for sessions (free scalability). Since most frameworks do not choose JWTs for sessions (in their inbuilt solution), devs choose to use something else and make mistakes like storing the JWTs in localstorage. Incorrectly configuring sessions in these frameworks can also cause issues. For example, during development, secure attribute for cookies is usually set to false. Sometimes, devs forget to set them to true for production use. Another example is that during development, your API is on api.example.com, but your site is on localhost. For this to work, you set sameSite to none, and forget to switch it to lax for production. SuperTokens aims to be very opinionated in order to prevent such mistakes (...catching these errors is not yet implemented though, but soon). -> Conclusion: Overall, the in built sessions in the frameworks are good for many apps. However, for those "serious" or complex apps, people end up building something custom (and that's a lot of companies ~ 50% of our YC batch built a custom solution or used JWTs despite of inbuilt sessions in their framework). Our solution is for such people.

candiddevmike 6y ago

Additionally, OWASP publishes so many guides on session management, along with checklists, to make it easy to see state of the art and best practices in this domain.

rishabhpoddar 6y ago
They do! But most open source solutions to not follow them, which means most apps do not follow them, and for those who care about OWASP session guidelines, need to mostly build their own system.

jrexilius 6y ago

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.

tompic823 6y ago

> It seems like very little effort to implement this yourself in a way that doesn't involve completely trusting a different company. What about cookie configuration (secure, httpOnly, samesite), signing, expiration, session management, etc? Getting and setting the cookie value are the easy part. For someone entrenched in appsec, most of these are fairly easy. But most developers are not entrenched in appsec. For proof of this, look at the popularity of Auth0.

rishabhpoddar 6y ago
Thanks! And more proof for this comment is the sheer number of questions / blog posts written about sessions and JWTs almost weekly on reddit, HN, stackoverflow etc.. If this was very simple to solve, securely, those questions, blog posts would not exist.

PaulHoule 6y ago

I think the problem is that websites today don't have enough single points of failure or maybe that websites today have too few third parties with access to private information. Something like that. It reminds me of the fad to get people to use "Javascript CDNs" that are "free" because they track your users with cookies.