Readit News logoReadit News
holtalanm commented on JavaScript Object Signing and Encryption is a bad standard (2017)   paragonie.com/blog/2017/0... · Posted by u/IggleSniggle
inshadows · 4 years ago
Set counter = 0 in DB. Put it into JWT. Increment the counter in DB to revoke the user. Compare counter in JWT < counter in DB. What's the problem?
holtalanm · 4 years ago
then you're hitting the db on every request just to do auth.

if you _had_ to do that, I would put the counter into something like redis instead.

holtalanm commented on JavaScript Object Signing and Encryption is a bad standard (2017)   paragonie.com/blog/2017/0... · Posted by u/IggleSniggle
vbezhenar · 4 years ago
holtalanm · 4 years ago
watched the whole thing. was very informative. Actually havent used RSA in any capacity in years (AES is a lot easier to use), but always viewed RSA as a battle-tested encryption method/alg. I suppose with anything there are ways to misuse it, and RSA appears to be really easy to misuse.
holtalanm commented on JavaScript Object Signing and Encryption is a bad standard (2017)   paragonie.com/blog/2017/0... · Posted by u/IggleSniggle
cmeacham98 · 4 years ago
The ability to logout existing sessions (typically either via a manual user action or automatically upon changing/resetting their password) is a desirable feature in essentially all applications where user accounts can be compromised.

You can kind of fake this by using a short-lived JWT and constantly refreshing it, but this:

1. Massively increases server strain and bandwidth usage

2. Has problems with users less reliable connections (they'll be randomly logged out all the time)

3. Makes "Remember Me" style features impossible (unless you use a server-side store for that, which brings us back to it not being stateless)

Here's a good graph on why $method to make JWTs work for sessions is bad: http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo... (note: for some reason the website doesn't support HTTPS :( )

holtalanm · 4 years ago
> 1. Massively increases server strain and bandwidth usage

A short-lived JWT that fits into an HTTP Header is not going to _massively_ increase your bandwidth usage. At most, you will end up with a single refresh request every few minutes as each short-lived JWT expires.

> 2. Has problems with users less reliable connections (they'll be randomly logged out all the time)

Usually if your request failed due to a bad connection, the client wouldn't be designed to automatically log out the user. That would be just terrible UX.

> 3. Makes "Remember Me" style features impossible (unless you use a server-side store for that, which brings us back to it not being stateless)

Incorrect. A short-lived JWT tied to a refresh token allows for a remember-me style feature by checking account access when issuing a new JWT token.

holtalanm commented on JavaScript Object Signing and Encryption is a bad standard (2017)   paragonie.com/blog/2017/0... · Posted by u/IggleSniggle
coding123 · 4 years ago
I'm sure there are employees out there that have their self destruct scripts ready to go. If they are ever terminated they have 10 minutes of token validation time to blow everything up.
holtalanm · 4 years ago
that would be insanely illegal.
holtalanm commented on JavaScript Object Signing and Encryption is a bad standard (2017)   paragonie.com/blog/2017/0... · Posted by u/IggleSniggle
tuyiown · 4 years ago
Access revocation: sometimes it's critical to block access to an issued token, without trusting the client to comply with revocation, especially for malicious cases.

Enforcing this implies to implement access control on each (critical) request, giving little advantage to a self contained token compared to a pure stateful signed session token.

holtalanm · 4 years ago
Yeah, if you need that kind of control over token access, then im not certain a jwt is the right tool for the job. For most use-cases a short-lived jwt is fine, as it expires in a matter of minutes, or even seconds, depending on configuration.
holtalanm commented on JavaScript Object Signing and Encryption is a bad standard (2017)   paragonie.com/blog/2017/0... · Posted by u/IggleSniggle
pcstl · 4 years ago
I believe they are mentioning the fact that the server cannot unilaterally log the user out in a "naive" JWT-based implementation without storing and checking a token blocklist - which makes the session no longer stateless.
holtalanm · 4 years ago
I can see that. I suppose when people say they need 'server-side session storage' I start thinking of app state, but in reality it could be as simple as storing a jwt refresh token that would be considered valid.
holtalanm commented on JavaScript Object Signing and Encryption is a bad standard (2017)   paragonie.com/blog/2017/0... · Posted by u/IggleSniggle
upofadown · 4 years ago
>Most cryptographers recommend migrating away from RSA.

They do? This strikes me as an exceptional statement that smacks of crypto fandom especially when combined with a later complaint that their favourite curve is not supported.

holtalanm · 4 years ago
i have never seen anything anywhere advocating for moving away from RSA. i'm curious to see what their sources are for this claim.
holtalanm commented on JavaScript Object Signing and Encryption is a bad standard (2017)   paragonie.com/blog/2017/0... · Posted by u/IggleSniggle
cmeacham98 · 4 years ago
My understanding is the use of JWTs for session management is 99% of the time bad (tldr: you think you get "stateless" sessions but in reality you still need server side state for useful features like logging out); but its use for auth (i.e. via OIDC) is a normal and good use case.
holtalanm · 4 years ago
> in reality you still need server side state for useful features like logging out

im curious about this. normally 'logging out' just involves deleting the secure http-only cookie where the jwt was stored. is there something I'm missing here?

holtalanm commented on Console Do Not Track – Proposal for a standard environment variable   consoledonottrack.com... · Posted by u/thih9
traverseda · 4 years ago
Because what I really want is a ton of different random bullshit enviroment variables next time I go to debug something :/
holtalanm · 4 years ago
well, good luck getting buy-in from the cli tool devs, then? the other option requires absolutely zero buy-in from homebrew, gatsby, dotnet, or any other cli.
holtalanm commented on Console Do Not Track – Proposal for a standard environment variable   consoledonottrack.com... · Posted by u/thih9
maddyboo · 4 years ago
I am. The terminal is one of the few places I am not being tracked. It’s also a portal into my most private data and activity, so if there’s one place I don’t want to be tracked, it’s here.

I do not long for a future where the terminal ecosystem resembles the state of the greater internet with regards to privacy and tracking. We’ve collectively watched it happen to almost every other segment of technology in the past 20-odd years, so it’s not far fetched to believe it could happen here as well.

holtalanm · 4 years ago
are there documented cases of these cli tools abusing their telemetry? are they entirely used to pinpoint performance issues and bugs within the tools that implement this telemetry tracking?

if it is the former, i can see there being cause for concern. if it is the latter, this is just pure fear-mongering.

u/holtalanm

KarmaCake day1276May 16, 2016View Original