Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON Web Tokens vs. Sessions

float-middle.com

Post reply on HN
Print view View original

141–150 of 173 posts

Re: JSON Web Tokens vs. Sessions

#141

Post by ams6110 »

lobster_johnson wrote: post #135
DenisM wrote: post #130

Earlier quoted context omitted.

The entire last paragraph of my pevious post describes one way to deal with it, without consulting a central session store.

By previous post, did you the bit about "Federation becomes moderately difficult"? I don't know if you've ever developed microservices, but building this logic into every single microservice would be a lot of work. We have dozens of microservices, written in different languages, so even if we wrote some generic glue as a library, we'd have to write it at least three times (Go, Ruby and Node.js).

Stop using so many different languages?

Re: JSON Web Tokens vs. Sessions

#142

Post by dexterdog »

jeremyjh wrote: post #38
dexterdog wrote: post #32

Earlier quoted context omitted.

But you're not storing the session there, just the key/token so you can change it. The session payload is still completely in the JSON body maintained by the client and sent with each request.

What difference does that make? Once you commit to this you have to do a database lookup for every request. Why not keep the session data there?

You only have to validate the token. It doesn't have to be a database-type medium because you're not writing very often in fact all you're really doing is making sure the token is not invalid. The session data could be changing on every request which would be at least one write on every request. With this system you are only writing to the central medium on a session creation or a session invalidation.

Re: JSON Web Tokens vs. Sessions

#143

Post by bigonlogn »

jastanton wrote: post #138
lllorddino wrote: post #133

Earlier quoted context omitted.

Is there anything wrong with saving the token in the cookie? I'm not exactly sure how to save them in the header. I'm guessing save it to localStorage and use javascript to pass it back to the server?

This article talked a bit about putting them in cookies: The header method is preferred for security reasons - cookies would be susceptible to CSRF (Cross Site Request Forgery) unless CSRF tokens were used. Secondly, the cookies can be sent back only to the same domain (or at most second level domain) they were issued from. If the authentication service resides on a different domain, cookies require much more wild cr…

You can also supply an options object (including headers) as the second argument[1].

[1]https://developer.mozilla.org/en-US/docs/Web/API/GlobalFetch...

Re: JSON Web Tokens vs. Sessions

#144

Post by bigonlogn »

dexterdog wrote: post #142
jeremyjh wrote: post #38

Earlier quoted context omitted.

What difference does that make? Once you commit to this you have to do a database lookup for every request. Why not keep the session data there?

You only have to validate the token. It doesn't have to be a database-type medium because you're not writing very often in fact all you're really doing is making sure the token is not invalid. The session data could be changing on every request which would be at least one write on every request. With this system you are only writing to the central medium on a session creation or a session invalidation.

This is not entirely true. Since we talking about implementing stateful sessions, you could receive a valid token (stolen, out otherwise) after the user has logged out.

You are correct that the lookup doesn't have to be via the database. You could implement a caching system where the cache is invalidated when the user logs out and requires reauthentication. This is the notion of the session. By definition they cannot be stateless.

Stateless authentication is inherently (slightly) less secure than sessions. I think of a blind librarian who gives out keys to the library. Whoever has a key has access. You can put limitations on the timeframe someone has access to the library, but that's it. If your key gets stolen, the blind librarian can't help you as there is no way for him to tell if it's really you.

Re: JSON Web Tokens vs. Sessions

#145

Post by joshwa »

lobster_johnson wrote: post #135
DenisM wrote: post #130

Earlier quoted context omitted.

The entire last paragraph of my pevious post describes one way to deal with it, without consulting a central session store.

By previous post, did you the bit about "Federation becomes moderately difficult"? I don't know if you've ever developed microservices, but building this logic into every single microservice would be a lot of work. We have dozens of microservices, written in different languages, so even if we wrote some generic glue as a library, we'd have to write it at least three times (Go, Ruby and Node.js).

Put it in the API gateway?

Re: JSON Web Tokens vs. Sessions

#146

Post by saynsedit »

jsmeaton wrote: post #98
saynsedit wrote: post #16

[headerB64, payloadB64, signatureB64] = jwt.split('.'); if (atob(signatureB64) === signatureCreatingFunction(headerB64 + '.' + payloadB64) { // good } else // no good } You really need a constant time compare for the signature, else you leak information about the correct signature in the timing of the response.

I don't think this is true. Timing attacks are only really useful if you can change a single piece of data and analyze the time difference until you find the right value, over and over again. Like comparing a password. The unknown data in the signature creating function is a key. The output is a hash. If you were trying to capture the key you would need to guess what the key was to get the correct hash. Each byte you…

This is not about retrieving the key, an attacker can still retrieve the correct opaque signature for specific data. This potentially allows an attacker to impersonate a user.

Re: JSON Web Tokens vs. Sessions

#147

Post by garfij »

pags wrote: post #131
areed wrote: post #101

Earlier quoted context omitted.

Because you can set Secure and HttpOnly flags on cookies? This merely brings them up to the same level of security you get with Local Storage. http://blog.portswigger.net/2016/05/web-storage-lesser-evil-...

What is a "level" of security? If I'm able to inject arbitrary code into your page, with it I can access your local storage data, but I can't access your "http only" cookies - so there's at least some "level" of difference.

If you're at the point where someone can inject random code into your site, you've already lost and have so many more problems than access to localStorage.

Re: JSON Web Tokens vs. Sessions

#148

Post by markdog12 »

Xeoncross wrote: post #95
hit8run wrote: post #67

A similar approach are encrypted cookies. You can take data and sign it. The server can then check if the cookie data is correctly signed and accepts or rejects the data in the cookie. This approach also scales horizontally. I use it for a while now in go ( http://www.gorillatoolkit.org/pkg/sessions ). If you want you can also encrypt the expiry date into the secured cookie.

Yes, I've been using encrypted cookies for years. If the user wants to use my website - they can store their own session data. The trade-off is extra bytes over the wire as the cookie is sent each same-domain request.

Not if you use HTTP2

Re: JSON Web Tokens vs. Sessions

#149

Post by jsmeaton »

saynsedit wrote: post #146
jsmeaton wrote: post #98

Earlier quoted context omitted.

I don't think this is true. Timing attacks are only really useful if you can change a single piece of data and analyze the time difference until you find the right value, over and over again. Like comparing a password. The unknown data in the signature creating function is a key. The output is a hash. If you were trying to capture the key you would need to guess what the key was to get the correct hash. Each byte you…

This is not about retrieving the key, an attacker can still retrieve the correct opaque signature for specific data. This potentially allows an attacker to impersonate a user.

The signature is already available - it's literally appended to the output. Verifying the signature is done by hashing the body with a secret (key) and comparing it to the known signature.

    "Known" === HMACSHA256(payload, secret)
You already know the left hand side. How would a constant time comparison protect you from a timing attack in this scenario? It wouldn't. The signature is known, the payload is known, but the secret is not known. That means you'd have to attack the secret, which you could even do offline. By iteratively changing the secret, even if you were to get the first half of the hash right, the next character you change would potentially change every single character in the output.

JWT/JWS does not concern itself with keeping the token secret or providing encryption. It's only concern is message authentication. If you leak your token, someone else can impersonate you, just like if you'd leaked your session cookie. The only viable attack on the scheme is to brute force (or discover) the secret, which would allow you to sign a message of your choosing. Once you can sign a message as if you were the server, then you may impersonate anyone you choose.

Re: JSON Web Tokens vs. Sessions

#150

Post by levelist_com »

intrasight wrote: post #96
geuis wrote: post #61

How does this avoid the problem of a 3rd party getting your jwt token? Then they can do any request as you.

Tying the token to an IP address will largely ameliorate that issue. As always, there is a tradeoff of security and convenience. I've worked at facilities with no internet access, where hard drives were removed and put in safes at the end of the day, and that had "leper lights" which flashed when unsecure people like me were present. Very secure but hardly convenient. You always need to ask yourself what it is that y…

You should not tie any functionality, user experience, and last but certainly not least, security to an IP address. IP addresses can be spoofed rather easily, using public wifi, hotel/guest networks, and even certain ISPs means the rotating of IP addresses on each user request.
Post reply on HN