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

91–100 of 173 posts

Re: JSON Web Tokens vs. Sessions

#91

Post by lobster_johnson »

spriggan3 wrote: post #88
lobster_johnson wrote: post #86

Earlier quoted context omitted.

The user does have a session. Tokens are temporary, short-lived authorizations. Sessions require a central session store; every request has to go to the central session store to check the session's validity. Incurring one session check per API call is bad enough, but when each API call then invokes half a dozen other APIs, you have a problem. Central session stores don't scale with distributed architectures. I've not…

> Central session stores don't scale with distributed architectures. Sessions stores scale as much as anything else.

Not what I was referring to. They scale just fine on their own, but the surrounding architecture doesn't when it becomes involved for every single call.

Simple scenario: Let's say user X wants to update document Y, which involves fetching a photo, processing it and storing it as Z. To read Y, we need to check the session. To update Y, we need to check the session. To store the photo, we need to check the session. We're already up to three roundtrips to the session store.

Some interactions require a lot more participants, each of which need to check the store. Over and over again, even though _clearly_ the world hasn't changed the last 300ms. If one API requires 6 calls to its partners, that's 6 times more roundtrips than necessary.

Re: JSON Web Tokens vs. Sessions

#93

Post by jessaustin »

wtbob wrote: post #30
moyok wrote: post #24

The thing that scares me about using JWT is that all security completely relies on the one secret that is used to sign tokens - any person with access to that secret has got potentially unlimited access to the app. They can now impersonate any user and do basically anything.

Yes, it'd be better if JWTs were full-fledged certificates, where ultimate authority could be confined to some offline key, who delegates authority for strictly delimited period to online keys. Or ultimate authority could belong to k out of a collection of n keys: one would need to suborn k keys to suborn the authority as a whole. RFCs 2692 & 2693 specify a really great, lightweight, way to do that. They resulting ce…

Sometimes it's good to use asymmetric crypto, and those RFCs could perhaps be suitable for that. My impression of the parent comment is not that of a preference for asymmetric over symmetric, however, but rather of a lament that key-based crypto is defeated when attackers learn keys. After all the complaint about secret keys applies just as well to private keys.

Re: JSON Web Tokens vs. Sessions

#94

Post by jessaustin »

moyok wrote: post #24

The thing that scares me about using JWT is that all security completely relies on the one secret that is used to sign tokens - any person with access to that secret has got potentially unlimited access to the app. They can now impersonate any user and do basically anything.

The thing that scares me...

You should rotate your keys often enough to alleviate your fears. You probably ought to trust your MAC a lot more than you trust other links in the key-security chain, anyway.

Re: JSON Web Tokens vs. Sessions

#95

Post by Xeoncross »

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.

Re: JSON Web Tokens vs. Sessions

#96

Post by intrasight »

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 you are securing.

Re: JSON Web Tokens vs. Sessions

#98

Post by jsmeaton »

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 change results in a cascade of changes in the output. You can't get information about the key from a timing attack on a hash function. I think.

Re: JSON Web Tokens vs. Sessions

#99

Post by girvo »

joepie91_ wrote: post #80
nbarbettini wrote: post #47

Earlier quoted context omitted.

> The less crypto is being used, the fewer mistakes are being made. I don't understand this position. What do you mean by "fewer mistakes are being made"?

Cryptography-related code is incredibly easy to fuck up, and the tiniest mistake can completely break your security model. A mistake that could be insignificant in other kinds of code, could easily be critical in crypto-related code. Thus, you reduce both the amount of mistakes and the impact of mistakes by avoiding crypto where possible. EDIT: Yes, this includes using existing libraries. It's not just the implementa…

In fact, a heap of JWT libraries had massive vulnerabilities in them not that long ago, that mean you could easily forge JWTs.

Re: JSON Web Tokens vs. Sessions

#100

Post by kalleboo »

lobster_johnson wrote: post #86
joepie91_ wrote: post #79

Earlier quoted context omitted.

The problem is that you're trying to treat sessions and authorizations as one and the same thing. They're not. What kind of services are you envisioning? Direct-to-database services like Firebase are a horrible idea for a plethora of security-related reasons, and if you control both service B and C yourself, then you either a) use one-time authorization tokens for stateless services or b) exchange a one-time authoriz…

The user does have a session. Tokens are temporary, short-lived authorizations. Sessions require a central session store; every request has to go to the central session store to check the session's validity. Incurring one session check per API call is bad enough, but when each API call then invokes half a dozen other APIs, you have a problem. Central session stores don't scale with distributed architectures. I've not…

There was a solution to that situation proposed here[0] where you keep using session tokens on the user end (so you can still do stuff like revoke sessions), but convert that to a signed token for all internal API calls.

[0] http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-...

Post reply on HN