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

JWT is Awesome

thehftguy.com

Post reply on HN
Print view View original

141–150 of 170 posts

Re: JWT is Awesome

#141

Post by tracker1 »

drinchev wrote: post #130
tracker1 wrote: post #97

Earlier quoted context omitted.

Don't blacklist, use shorter lived tokens and have the client refresh as needed. A 10-15m token is plenty long life and not so long as it's a huge risk window, more than even a shorter window,.

So where do you store the ones that should not allow to be refreshed? How short lived they should be in case of "Reset Password" scenario, when you need to kick out malicious user?

You can still do a redis or memcached, or even an rdbms table for that matter on revoked tokens... and do a lookup for critical systems... You don't need to do that on EVERY request though. It's really not less difficult than a session server/service/database, and more likely to scale better.

Re: JWT is Awesome

#142

Post by tracker1 »

jteppinette wrote: post #137
tracker1 wrote: post #97

Earlier quoted context omitted.

Don't blacklist, use shorter lived tokens and have the client refresh as needed. A 10-15m token is plenty long life and not so long as it's a huge risk window, more than even a shorter window,.

Stakeholder: “so you are saying that after a user is denied access they can still access the resources?” Dev: “yes, but only for 15 minutes. Also, it makes our system more simple and decreases database calls, increase performance, ...” Stakeholder: “nope”

Usually in one of those scenarios, you will try to hold, say a fired employee for that long in order to deactivate all their accounts and access anyway... in reality it's not much of an increased risk...

You still could blacklist, but realistically most areas don't need a dedicated revocation check. Some critical areas might, depending on the space.

Re: JWT is Awesome

#143

Post by tracker1 »

bearjaws wrote: post #138
jteppinette wrote: post #137

Earlier quoted context omitted.

Stakeholder: “so you are saying that after a user is denied access they can still access the resources?” Dev: “yes, but only for 15 minutes. Also, it makes our system more simple and decreases database calls, increase performance, ...” Stakeholder: “nope”

Meanwhile on sales call with Microsoft: "Authentication takes a few minutes to replicate throughout our systems so a SLO request should be resolved within a few minutes". Stakeholder: Ok sounds good

+1 on this... it can be up to a 30 minute lag in some orgs... oh, you have access to those systems for a while until things sync up... similar for LDAP/AD sync with Nix/windows.

Re: JWT is Awesome

#144

Post by throwaway3157 »

jteppinette wrote: post #137
tracker1 wrote: post #97

Earlier quoted context omitted.

Don't blacklist, use shorter lived tokens and have the client refresh as needed. A 10-15m token is plenty long life and not so long as it's a huge risk window, more than even a shorter window,.

Stakeholder: “so you are saying that after a user is denied access they can still access the resources?” Dev: “yes, but only for 15 minutes. Also, it makes our system more simple and decreases database calls, increase performance, ...” Stakeholder: “nope”

I actually have this conversation a lot, and the answer is usually "okay" and rarely "nope". Stakeholders have to weigh many more pros and cons.

Re: JWT is Awesome

#145

Post by scarmig »

CiPHPerCoder wrote: post #48
Aeolun wrote: post #41

Earlier quoted context omitted.

As soon as AWS supports PASETO we can talk, until that time popularity equals value.

Give me a few months, then. :P If they agree it's a good idea, it should pick up quickly.

Rooting for you! It's a good idea, and successfully popularizing it would provide a huge amount of value to the world.

Re: JWT is Awesome

#146

Post by dwaite »

blablabla123 wrote: post #89
tmikaeld wrote: post #35

Earlier quoted context omitted.

If you cryptographically sign the session cookie, as suggested in the video, then you accomplish the exact same thing as a JWT token - so, then why use JWT at all, if you going to look up the session data from the database in any case. JWT was meant to be stateless, if it's not, then it's just a layer of unnecessary complexity with potential security and implementation flaws.

JWT is basically a spec for how to sign the session cookie. Correct me if I'm wrong but there are 2 fundamentally different ways to do user session management: a) user has a random key that can be compared to stored key (DB, Redis, ...) b) signed session information, probably stored as cookie. It's possible to add additional information in a JWT. And of course it's complexity that adds additional attack surface, but…

Nit: JWTs are leveraged to cover a wide variety of use cases outside sessions.

Re: JWT is Awesome

#147

Post by dwaite »

twic wrote: post #40
teyc wrote: post #32

https://news.ycombinator.com/item?id=21785888 tptacek Credential attenuation in Macaroons is cryptographic; it's in how the tokens are constructed. I don't see the opportunity for a DoS (that didn't exist without attenuation already). Macaroons are a really lovely, tight, purpose-built design that happens to capture a lot of things you want out of an API token, including some things that JWTs don't express naturally…

I'd never heard of macaroons. Here is a website: http://macaroons.io/ I note that the logo depicts macarons [1], rather than macaroons [2]. A parent comment also mentions PASETO: https://paseto.io/ Sadly, a paseto does not appear to be any kind of biscuit. The PASETO site links to this searing indictment of JWTs and related things: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba... I am far from qualifie…

I hear macaroons come up fairly often, but they suffer from being only described by a Google research paper, without a standard or other sufficient formal specification. My understanding is that compatibility across implementations is lacking.

PASETO is by Paragon, the authors of said searing indictment.

IMHO their argument really comes down to a difference in opinion in how cryptography should be supplied to developers. TLS and JWT standards allow for a wide variety of cryptographic algorithms, and implementations may provide various ways to negotiate that set of algorithms, such as whitelisted set.

This provides for migration over time from legacy systems to new algorithms, but creates a risk that the library author will have a security issue in their implementation of the standard, or that the application developer will misconfigure said implementation.

The alternative strategy is something like NaCL/libsodium http://nacl.cr.yp.to, where experts standardize on single packages of algorithms (or extremely limited set, such as one standard and one legacy) to implement specific cryptographic primitives.

The problem usually quoted here is one of compatibility, migration, and experimentation. There are often no provisions for older systems which cannot handle one of the profiles involved, or primitives for managing non-standard cryptographic sets. Many of these specifications also dictate removal of an old algorithm set to add a new one - making the specification only really valid in lock-step upgraded systems.

Re: JWT is Awesome

#148

Post by user5994461 »

peeters wrote: post #114
nijave wrote: post #25

Earlier quoted context omitted.

That video is ridiculous. The whole time is spent talking about how cookies are superior to local storage which has little to do with JWT. You can use JWT and store it in a cookie. Session cookies are most certainly not automatically signed. Signing a session ID provides absolutely no value (signing claims, however, does). Revocation is exactly the same for both of them. JWT has a standard jti field for the session I…

Yeah I was hoping for a fair comparison but it seemed like a pretty big strawman. Like he just takes it for granted that "a session cookie is a cryptographically-signed identifier" but that's not remotely standard. At its most common (looking at you, JSESSIONID), simple form, the session cookie is a securely generated random number that is used as an index for state, and signing plays no part. The presenter then goes…

Author here. Random identifiers and encoded objects are both widely used historically. Random cookies might have been more common 2 decades ago when every byte was expensive, but that was a while ago.

If you work mainly in Java for example, you'll more often see JSESSIONID which are random string identifiers, referring to a database containing active tokens and user profiles.

However if you work in Python, you'll more often see objects. Typically something like a user identifier + creation date + random bits, that is encrypted with a symmetric key. It's usually encrypted, not signed, so yet another thing than signed tokens and random cookies.

Re: JWT is Awesome

#149

Post by logicalmind »

tracker1 wrote: post #97
miguelmota wrote: post #86

Reasons why JWTs are not awesome: - to revoke a JWT you have to blacklist it in the database so it still requires a database call to check if it's valid. - JWT are to prevent database calls but a regular request will still hit the database anyway. - JWT are very large payloads passed around in every request taking up more bandwidth. - If user is banned or becomes restricted then it still requires database calls to ch…

Don't blacklist, use shorter lived tokens and have the client refresh as needed. A 10-15m token is plenty long life and not so long as it's a huge risk window, more than even a shorter window,.

But isn't the requirement for using the refresh token that it must be kept secure? For example, if you users authenticate in a browser, they get back an access token and a refresh token. If that refresh token were stolen on the wire or from within the browser, how would you prevent someone from using that refresh token perpetually if you're not blacklisting?

Re: JWT is Awesome

#150

Post by dwaite »

sk5t wrote: post #74
jmkni wrote: post #34

Earlier quoted context omitted.

Noob question, what is pinning in the context of JWT?

Your question is a good one, and "pinning" is not a very appropriate term here. Whitelist acceptable algorithms by issuer, ok fine--you have to have a library of acceptable public keys or shared secrets to go along with each of the allowed algorithms anyway. The JWT consuming infrastructure here on top of jose4j uses a registry of keyinfo metadata to allow for provision of multiple expirable keys and supported algori…

> Maybe it was foolish to ever make any allowance for this in the first place.

Since JWT is used as a wrapper around data, it is possible that your needs will vary based on deployment scenario. In some cases, that data may need to be encrypted, in other cases only signed.

In some cases I may not need integrity protection/repudiation and am already sending over a mutually authenticated/encrypted channel. The implementations may not want signing to be forced on them, impacting their compute/data budgets - but they still want to write their standards to depend on a single data format.

In general there should not be a whitelist, but a precisely known strategy going into evaluation. This is because: - unlike TLS, you likely have a relationship with the issuers - unlike browsers, the different components are being validated against the domain

For JWKS-based distribution, that usually means that a key identifier maps to a specific issuer and to a specific validation strategy. If you supported CA-based trust models, that specific validation strategy should come from the certificates.

You shouldn't look at the public key data and decide based on the algorithm inside the JWT how to interpret it.

Post reply on HN