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

Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful

insomniasec.com

Post reply on HN
Print view View original

81–90 of 97 posts

Re: Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful

#81

Post by masklinn »

user5994461 wrote: post #63
applecrazy wrote: post #5

Earlier quoted context omitted.

> the option to have 'alg: none' should never be used I doubt anyone uses this deliberately (edit: except maybe for internal server to server communications?). I agree that having it as an option is a footgun. I still think this is a non-issue on the client/backend, most libraries explicitly make you whitelist token signing algorithms and will throw errors if the token isn't signed with the right algorithm. > Even gi…

Protocols agility allow applications to pick between multiple settings, let's say RSA128 and RSA256 for example. This allows to add and remove ciphers over time, which is very important. In theory it's a bad idea, because it means stuff might select obsolete ciphers during operation, which is bad. In practice, there is no choice but to design agility. Ciphers will invariably get weak after some years (computer get fa…

This is exactly backwards.

In theory cipher agility is useful so you can upgrade your suite over time, in practice it’s a terrible idea because it will, and has time and again, lead to downgrade attacks.

Crypto researchers have learned this fact of life the hard way, crypto systems are becoming less “agile” over time because this agility means it’s preemptively broken.

Re: Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful

#83

Post by JdeBP »

eximius wrote: post #4

Always normalize your input?

Try:

Don't encode your machine-to-machine protocol as human-readable strings, leading to things like declaring machine-readable identifiers to be case-insensitive when only the humans need this, not the machines.

Re: Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful

#84

Post by JdeBP »

deathanatos wrote: post #77
theamk wrote: post #67

Earlier quoted context omitted.

The answer to that is we should not be using _any_ case-insensitive strings in protocols. They are fine for human-visible names, but field names and internal enum values should use byte-by-byte comparison. It just makes entire class of vulnerabilities go away.

They are case-sensitive. > The "alg" value is a case-sensitive ASCII string containing a StringOrURI value. This Header Parameter MUST be present and MUST be understood and processed by implementations.

But the protocol says that they are case-insensitive! is not a good response to the assertion that machine-to-machine protocols should not be case-insensitive, which is what theamk said.

Re: Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful

#85

Post by ZenPsycho »

de_watcher wrote: post #80
ZenPsycho wrote: post #79

Earlier quoted context omitted.

JWT has nothing to do with javascript, other than being one of the many many languages that have JWT implementations.

It has a huge vibe of incompetent reinwheeling that is natural to the javascript ecosystem because of the web explosion that gave us a large amount of people with no clue.

Just because you have a poisoned view of javascript doesn't mean that everything bad has something to do with javascript. In this case JWT was designed by a C# developer at Microsoft. Maybe you can shift gears to whining about .NET in every thread now?

Oh hey look, he standardised POSIX threads. maybe everything bad is from POSIX?

https://www.microsoft.com/en-us/research/people/mbj/

Re: Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful

#86

Post by de_watcher »

ZenPsycho wrote: post #85
de_watcher wrote: post #80

Earlier quoted context omitted.

It has a huge vibe of incompetent reinwheeling that is natural to the javascript ecosystem because of the web explosion that gave us a large amount of people with no clue.

Just because you have a poisoned view of javascript doesn't mean that everything bad has something to do with javascript. In this case JWT was designed by a C# developer at Microsoft. Maybe you can shift gears to whining about .NET in every thread now? Oh hey look, he standardised POSIX threads. maybe everything bad is from POSIX? https://www.microsoft.com/en-us/research/people/mbj/

"You have a poisoned view"? That's just your opinion. I tried to base mine on a somewhat objective observation about speeds and volumes of stuff happening.

"Everything bad has something to do with javascript"? Don't put words in my mouth.

"A C# developer at Microsoft" plus a javascript explosion. Aren't you just confirming my point? Those new people didn't materialise out of thin air, they may have been software developers who had to change focus rapidly. And they didn't necessarily knew how their creations could be misused under the rules of that new javascript world.

And he doesn't look old enough to be a designer of POSIX threads.

(if you don't like my expression about the "vibe" then I'll give you an example of a protocol with a C vibe: the type value would be a fixed-length field with a table of integer IDs written in the standard; everyone would complain about integer sign, wrap-arounds and the new extension field that was added because we ran out of IDs)

Re: Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful

#87

Post by ZenPsycho »

de_watcher wrote: post #86
ZenPsycho wrote: post #85

Earlier quoted context omitted.

Just because you have a poisoned view of javascript doesn't mean that everything bad has something to do with javascript. In this case JWT was designed by a C# developer at Microsoft. Maybe you can shift gears to whining about .NET in every thread now? Oh hey look, he standardised POSIX threads. maybe everything bad is from POSIX? https://www.microsoft.com/en-us/research/people/mbj/

"You have a poisoned view"? That's just your opinion. I tried to base mine on a somewhat objective observation about speeds and volumes of stuff happening. "Everything bad has something to do with javascript"? Don't put words in my mouth. "A C# developer at Microsoft" plus a javascript explosion. Aren't you just confirming my point? Those new people didn't materialise out of thin air, they may have been software deve…

This is conspiracy theory logic. You could literally use this same line of argument to blame anything bad on a vague "explosion of javascript", fact free. Not very impressive either since it relies on smearing people's competence and professionalism based on handwaving instead of any kind of serious engagement with the facts of the situation. Moving on.

Re: Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful

#88

Post by de_watcher »

ZenPsycho wrote: post #87
de_watcher wrote: post #86

Earlier quoted context omitted.

"You have a poisoned view"? That's just your opinion. I tried to base mine on a somewhat objective observation about speeds and volumes of stuff happening. "Everything bad has something to do with javascript"? Don't put words in my mouth. "A C# developer at Microsoft" plus a javascript explosion. Aren't you just confirming my point? Those new people didn't materialise out of thin air, they may have been software deve…

This is conspiracy theory logic. You could literally use this same line of argument to blame anything bad on a vague "explosion of javascript", fact free. Not very impressive either since it relies on smearing people's competence and professionalism based on handwaving instead of any kind of serious engagement with the facts of the situation. Moving on.

Numbers of developers and code aren't vague. They are disproportionately significant. And you don't even use arguments, just a low-effort labeling.

Re: Auth0 JWT Auth Bypass: Case-Sensitive Blacklisting Is Harmful

#89

Post by fulafel »

treve wrote: post #76
thinkshiv wrote: post #68

Hi all - Shiv from Auth0. I am the CPO and wanted to share some additional context here. On July 31st 2019, at 5:11 am, we received an email from Insomnia reporting a service vulnerability. By 11:00 pm the same day, we had fixed the issue in production. We analyzed the logs and validated that no one exploited the vulnerability. More details from our CSO here: https://auth0.com/blog/insomnia-security-disclosure/?utm_s…

Why did your implementation have a case-sensitive check for a fixed list of algorithms, and why are you blacklisting vs. whitelisting acceptable algorithms? 'Old, stable' codebase or not... this is production code for a security product and seems like something that would be picked up during an audit.

Not the OP but, the sad truth is that code audits aren't that good at eradicating bugs.
Post reply on HN