Hacker News Reader

Comment by rishabhpoddar | Hacker News Reader

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.

View on HN

> 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)?

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

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

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.

Got it. So it's not so much implementing known-good session management as it is implementing session management edge cases that allow for improved usability without significant compromises in security.

Is that a fair summary?

I wouldn't consider them as "edge cases" per say. It's an end to end session management solution that aims to be secure and covers all needs for simple and complex apps.

I suppose that depends on perspective. An argument can be made that a subset of the 50% of your YC batch are doing session management wrong if they're building a new app and feel they have to home-grow a solution.

That said, considering the standard guidance around session management is "don't do it yourself," then by delegating to you, your customers also distribute that risk to you and gain some amount of indemnity as a result. So using SuperTokens would be a valid risk management strategy provided firms are:

1. fine with what's essentially indefinite vendor lock-in (at least until they ditch the software platform they've written that relies on SuperTokens), and

2. doing their diligence around your security controls.

And if they've met those conditions and feel that paid session management gives them extra UX cases that they don't have available to them for building out their solution, then more power to them.

The only implicit guidance in all of this that I'll make explicit is to make sure you're investing in the security of your platform considering it's the product you're selling. Many of your customers who would consider buying into this service would do so knowing that it essentially comes with some amount of indemnification regardless of whether or not you disclaim it.

Final thought: it'll help you a lot if you clearly define a Shared Responsibility Model that outlines the security responsibilities SuperTokens will own v. the security responsibilities the implementing customer will own. What'll help even further is if you can then cement your Shared Responsibility Model and prove the controls you claim to have with e.g. a SOC2 type 2 that defines Complementary User Entity Controls.

There's a market for what you're offering, but you'll have to be strategic about capitalizing on it and not potentially becoming a victim of your own success as you acquire customers who themselves will be the targets of attacks- ergo attacks against your platform.

Noted. Thank you for the suggestions. I may reach out to you sometime in the future :)

Wish you the best in any case :)

Small typo in your pdf:

> Storing only the hased versions of session tokens

Thanks for pointing it out :)

Reply on news.ycombinator.com