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

JSON Web Tokens should be avoided

paragonie.com

Post reply on HN
Print view View original

271–280 of 304 posts

Re: JSON Web Tokens should be avoided

#271

Post by tracker1 »

jdmichal wrote: post #259
tracker1 wrote: post #241

Earlier quoted context omitted.

And if you want to be able to authenticate users to a service that you do not want to send private keys to?

Then sign / encrypt the token with a private key and distribute a public key to the untrusted peers. Since you're just using bog-standard cryptography primitives you can change them at will to match your use case. Need to handle untrusted peers? Asymmetric keys are the answer.

Or, you use the asymmetric key/pair to sign the JWT, and lock your environment to only public keys signed by your DC's cert in your org. If only that was supported by JWT.. oh, that's right, it is.

Nobody has to implement the FULL spec, you only need to allow what your environment needs.

Re: JSON Web Tokens should be avoided

#272

Post by deathanatos »

Illniyar wrote: post #252
deathanatos wrote: post #173

Earlier quoted context omitted.

The downside being that the browser will attach it to every request; if you use cookies, you MUST be aware of this, or you are (IMO) pretty much guaranteed to write a CSRF vuln. (I'm much more in the localStorage + Authorization header for this reason. I recommend [1] for reading. If malicious JS is running, cookies won't save you, since the malicious JS is capable of simply making the request itself, to which the co…

CSRF is the easiest vulnerability to avoid, a csrf token solves all csrf attacks. XSS is a lot harder to protect against, one of the better ways to mitigate it's effects is to use http only cookies

Well, I keep running into CSRF vulns. in the wild, so…

XSS is avoidable by systematically having a framework that escapes any inputs that are run through it. (jinja2, on the server, can do this, though it defaults to not, which I wish wasn't true.) I'm not saying that XSS is much better that CSRF, really; I've seen these, too.

the point (and that of the linked article) is more that either you're not subject to XSS, in which case localStorage is strictly better than cookies (it is default-secure), or you're subject to XSS, in which case neither saves you.

Re: JSON Web Tokens should be avoided

#273

Post by Zombieball »

bgentry wrote: post #213
tptacek wrote: post #77

Earlier quoted context omitted.

I don't care if you want to use stateless client tokens. They're fine. You should understand the operational limitations (they may keep you up late on a Friday scrambling to deploy a token blacklist), but, we're all adults here, and you can make your own decisions about that. The issue with JWT in particular is that it doesn't bring anything to the table, but comes with a whole lot of terrifying complexity. Worse, yo…

Assuming that: - your JWT libraries don't do anything dumb like accepting the `none` algorithm - you're using HMAC SHA-256 - your access tokens have a short (~20 min) expiration time - your refresh tokens are easily revocable Can you elaborate on the specific security advantages that a token encoded with ActiveSupport::MessageEncryptor would have over such a JWT implementation? Why do you think there aren't more AS::…

I'd also be interested in hearing an answer to this from tptacek.

My (limited) understanding is the security issues arise around the implementation & handling some of the default claims (NBF, IAT, etc.) and producing/verifying the signature.

But I don't quite understand how moving to a different format solves these issues?

Re: JSON Web Tokens should be avoided

#275

Post by unscaled »

tptacek wrote: post #210
unscaled wrote: post #205

Earlier quoted context omitted.

Agreed, but is there a better standard ? I'm also fine with just stuffing MsgPack or Cap'n Proto data inside a libsodium secretbox or usually just crypto_auth to be honest, but corporates love standard. Perhaps libsodium algorithms should be turned into RFCs and then we could have a much simplified token metadata format (expiry, issued date and their ilk) that can be separated from a completely freeform payload. I'd…

Sure: use Fernet. https://github.com/fernet/spec/blob/master/Spec.md It's an informal standard, like Noise, or WireGuard, or Curve25519, or Nacl. It's also so simple that JWT nerds will likely believe it's missing something. It is: the JWT/JOSE vulnerabilities. It used to be that we got things working and then standardized them. Now we build cryptosystems de novo in standards committees and spend the next 10 years wr…

Yes, informal standards, but that's exactly the problem. At my previous work, I've implemented something similar to Fernet in the past (though using AES-GCM rather than AES-CBC+HMAC), and that's dead simple. But it's not standard.

Every time I've suggested modifying our JWT implementation to use Ed25519, or using any NaCL implementation for encryption instead of the vulnerability-footgun framework better known as JCE, I get raised eyebrows.

People want standards. Fernet is nice, but it should be pushed to an RFC level and offer more metadata besides a timestamp (not hard, just copy all the JWT claim names in stick a JSON into the ciphertext :))

It's also not useful when you do need asymmetric encryption/signature, and you can't just ignore these use cases, since people will keep JWT alive just for them.

Re: JSON Web Tokens should be avoided

#276

Post by CiPHPerCoder »

andy_ppp wrote: post #261
joepie91_ wrote: post #258

Earlier quoted context omitted.

... and causes another security issue in the process, namely the ability to steal session credentials after an XSS attack. Trading in one security issue for another makes no sense. Just implement the correct mitigation against CSRF attacks; namely, CSRF tokens.

Yes but you can now concentrate make yourself XSS proof right; with an XSS you can still get someones cookies... unless you are talking HttpOnly. But we are probably talking single page webapps here anyway.

> unless you are talking HttpOnly

Which is precisely what the blog post that was hyperlinked in the sentence you were responding to was advocating.

Re: JSON Web Tokens should be avoided

#277

Post by detaro »

fcvarela wrote: post #35
detaro wrote: post #26

Earlier quoted context omitted.

EDIT: the secondary spec describing the algorithms is at least clear on the use of none, I missed that at first: Implementations that support Unsecured JWSs MUST NOT accept such objects as valid unless the application specifies that it is acceptable for a specific object to not be integrity protected. Implementations MUST NOT accept Unsecured JWSs by default. https://www.rfc-editor.org/rfc/rfc7518.txt Still, my point…

I don't think the spec meant to read that you must allow the client to be able to forge tokens by accepting tokens issued by it without an algo or signature. If you issue tokens with none, then you will have to accept them when clients send them back. This is obviously a very bad idea, but that's all th spec says. If the issuer chooses to be insecure, that is a valid choice. If you issue tokens with a specific algo,…

And the spec doesn't spell it out, and initial libraries implementations thus forgot to include things like "let the user specify which algos to accept". And if common libraries provide simple APIs, users expect that these APIs still provide good security.

A standard promoted as "the standard for secure tokens" should not aim for "You can use the pieces to build a correctly behaving system" or "the spec allows secure implementations", it should aim for "if you use this and follow some spelled-out basic rules you get fool-proof secure tokens" and make wrong usage as hard has possible.

Re: JSON Web Tokens should be avoided

#278

Post by hardwaresofton »

mkohlmyr wrote: post #82
hardwaresofton wrote: post #63

Can anyone think of some criticism for simply storing an API key and secret in localstorage for a web client? It's 50% bridging the gap between using cookies and a normal API and 50% simplifying frontends. The scheme I'm currently using on a project goes like this: 1. Web client ("offline-first" SPA app) hits HTTPS backend in with username and password 2. Web client receives a a generated API key and secret, which ex…

Perhaps I am missing something but I really don't see the point of storing it in localStorage or sessionStorage over cookies what so ever. 1. You have to write code to provide the authentication values in all requests. 2. The GET request for the initial page render can't possibly be authenticated. Why not cookies? Other than that I agree. I really don't see the point of following the JWT spec or using an implementati…

The reason I wanted to try this scheme was to finally remove the little difference in authentication method between web frontend and commandline/mobile API client...

OWASP says not to do it (https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#L...) but the stated reasons are kind of vague/I'm not sure the reasoning is sound.

If someone has physical access to the machine, all bets are off, and if a XSS vuln happens, pretty sure people can get whatever information they're looking for (including the cookie) anyway. The only real objection was the inability to restrict to HTTPS (path based, everything is just based on same origin regardless of scheme I think), however same origin policy still applies like normal.

I wasn't trying to recommend localstorage over cookies, more like just trying to see if there's any huge blindspot I was missing, everywhere I look says not to do this, but the reasons were never very satisfying.

Re: JSON Web Tokens should be avoided

#279

Post by hardwaresofton »

methyl wrote: post #88
hardwaresofton wrote: post #63

Can anyone think of some criticism for simply storing an API key and secret in localstorage for a web client? It's 50% bridging the gap between using cookies and a normal API and 50% simplifying frontends. The scheme I'm currently using on a project goes like this: 1. Web client ("offline-first" SPA app) hits HTTPS backend in with username and password 2. Web client receives a a generated API key and secret, which ex…

The biggest flaw for me is that any 3rd party script can access your localstorage without your knowledge, while it can't access HTTPonly cookies.

Thanks that's a valid point -- I previously misunderstood the HTTPonly cookie setting to mean restricting the cookie to HTTPS, but that's path-based restriction just now read about HTTPonly (https://www.owasp.org/index.php/HttpOnly).

To be honest though, once there's an unauthorized 3rd party script running on your page, that's a pretty dire already though. I guess it's possible to also protect a little from malicious web addons/extensions though.

Re: JSON Web Tokens should be avoided

#280

Post by igl »

Alex3917 wrote: post #262
igl wrote: post #260

Earlier quoted context omitted.

So there is a db roundtrip involved? Like a inverted session. Whats the point of using jwt then?

For most web frameworks, the user model gets retrieved from the db automatically whenever an authenticated request is made. So there is no extra lookup.

Oh man.

Proponents say critics dont offer alternatives at the same time they always literally 'reverse' engineered sessions if you dig deep enough.

I give up. JWT is just a hip thing to do right now. :(

Post reply on HN