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

Critical Vulnerabilities in JSON Web Token Libraries

auth0.com

Post reply on HN
Print view View original

31–40 of 55 posts

Re: Critical Vulnerabilities in JSON Web Token Libraries

#31

Post by michaelt »

laumars wrote: post #12

Can someone please explain to me the appeal of tokens like the following please? payload = '{"loggedInAs":"admin","iat":1422779638}' I've always worked under the assumption that everything the client sends is wrong; which means the only fields I issue are a user hash and session key. If either of those don't match the session table record then the token is rejected. Having group permissions issued from the client sid…

Once the token has a signature, three-legged authentication.

For example, a Netflix employee can log onto the Netflix Single Sign On system, and that system can issue them a signed token saying "The bearer of this token can log into this AWS account with these powers until this time". The employee presents this to AWS and, if the signature is valid, AWS lets them log on.

That way each employee only needs one account - on the Netflix Single Sign On system - instead of them also needing an AWS account (with a separate password, 2FA and so on).

(SAML is another standard for doing this, but it's a standard with a lot of unnecessary complexity)

Re: Critical Vulnerabilities in JSON Web Token Libraries

#33

Post by marcioaguiar »

ultrafez wrote: post #22
Kiro wrote: post #15

I don't understand why you need the alg property at all. I mean, you are the one issuing the token so you definitely know what algorithm is used in the back-end. Why is this necessary?

If you change your algorithm, your old tokens are still usable because you know which algorithm was used to create them.

It would not be possible to establish a period to migrate all tokens? This "if you change in a possible feature" is not a good argument when modeling something, in my opinion. That's how AbstractFactoryStrategies are made.

Re: Critical Vulnerabilities in JSON Web Token Libraries

#35

Post by jessaustin »

Kiro wrote: post #15

I don't understand why you need the alg property at all. I mean, you are the one issuing the token so you definitely know what algorithm is used in the back-end. Why is this necessary?

As the issues described in TFA make clear, the verifier really should know the algorithm in order to verify completely. However, since this format allows various algorithms, the algorithm must be recorded somewhere, especially in the public-key scenario when the verifier is probably not the signer.

Re: Critical Vulnerabilities in JSON Web Token Libraries

#36

Post by Kiro »

jessaustin wrote: post #35
Kiro wrote: post #15

I don't understand why you need the alg property at all. I mean, you are the one issuing the token so you definitely know what algorithm is used in the back-end. Why is this necessary?

As the issues described in TFA make clear, the verifier really should know the algorithm in order to verify completely. However, since this format allows various algorithms, the algorithm must be recorded somewhere, especially in the public-key scenario when the verifier is probably not the signer.

Thanks.

OT but what does TFA stand for? I've seen you use it in two threads and I presume it's referring to the posted article in question but I can't figure out the actual meaning.

Re: Critical Vulnerabilities in JSON Web Token Libraries

#37

Post by williamcotton »

Kiro wrote: post #36
jessaustin wrote: post #35

Earlier quoted context omitted.

As the issues described in TFA make clear, the verifier really should know the algorithm in order to verify completely. However, since this format allows various algorithms, the algorithm must be recorded somewhere, especially in the public-key scenario when the verifier is probably not the signer.

Thanks. OT but what does TFA stand for? I've seen you use it in two threads and I presume it's referring to the posted article in question but I can't figure out the actual meaning.

The F*ing Article... probably evolved from RTFM. Hacker culture, so warm and welcoming, isn't it?

Re: Critical Vulnerabilities in JSON Web Token Libraries

#38

Post by jessaustin »

williamcotton wrote: post #37
Kiro wrote: post #36

Earlier quoted context omitted.

Thanks. OT but what does TFA stand for? I've seen you use it in two threads and I presume it's referring to the posted article in question but I can't figure out the actual meaning.

The F *ing Article... probably evolved from RTFM. Hacker culture, so warm and welcoming, isn't it?

I've usually seen it as The Fine Article, but tastes vary. b^)

Re: Critical Vulnerabilities in JSON Web Token Libraries

#39

Post by sp332 »

williamcotton wrote: post #37
Kiro wrote: post #36

Earlier quoted context omitted.

Thanks. OT but what does TFA stand for? I've seen you use it in two threads and I presume it's referring to the posted article in question but I can't figure out the actual meaning.

The F *ing Article... probably evolved from RTFM. Hacker culture, so warm and welcoming, isn't it?

The abbreviation gives some plausible deniability - it could be "the fine article"!

Re: Critical Vulnerabilities in JSON Web Token Libraries

#40

Post by zaroth »

williamcotton wrote: post #37
Kiro wrote: post #36

Earlier quoted context omitted.

Thanks. OT but what does TFA stand for? I've seen you use it in two threads and I presume it's referring to the posted article in question but I can't figure out the actual meaning.

The F *ing Article... probably evolved from RTFM. Hacker culture, so warm and welcoming, isn't it?

That usage was deprecated by RFC19647. The correct definition is now 'The Featured Article'.
Post reply on HN