Hacker News new | ask | show | jobs
by simonw 2901 days ago
It looks like they are concerned that OAuth 2.0 doesn't include a cryptographic signature of the request body, as seen in OAuth 1.0.

My understanding is that OAuth 2.0 dropped that signature in favour of requiring TLS to protect against tampering. I'd be interested to know why Mastercard doesn't consider this to be as good as the request body signatures in OAuth 1.0.

3 comments

It's quite common for companies to MITM https requests (and install their personal certificate on all company owned machines so the browser raises no errors).

Some countries do so as well, for example Kazakhstan and China.

It's common to mitm TLS in banking sector in the US
And people from that country have those certificates installed? Voluntarily?
In case of countries, you don't need the certificate installed for MITM to work. You just need it if you want to get rid of the warning on every single https website. Unless you tunnel your traffic, it's visible.

In case of large corps, you get assigned a laptop / desktop setup by the company. You probably authenticate to the AD and don't even get the privileges to add/remove certificates.

Also, if the country has its own root CA, it can just sign arbitrary certificates. https://en.wikipedia.org/wiki/CNNIC#Fraudulent_certificates
Notice of course that that little stunt resulted in them being removed from everybody's trust stores. And it's not like you can just get away with it these days, since certificates are all publicly logged now.
> since certificates are all publicly logged now.

Only some of them are. All EV and some DV get published.

Not everybody's. There is whole China where the certs remain installed.
Just a single data point but the last time I was in Beijing, my iPhone prompted me to install a certificate before I could hop on to the airport WiFi.

I just spent the next 3 hours of the layover without internet.

Uyghurs in China need to install mandatory tracking app to their mobile phones.
From a technical PoV, it feels like it is easier to argue after the fact "look, you sent this message, you signed it", v.s. "trust us, all comms were over TLS, we promise our logs are accurate and your token was not leaked".
An argument I've heard against TLS is that it's easy for clients to get wrong. In some cases, client code needs to directly check that the certificate matches the intended domain, and forgetting to do so makes TLS worthless because an attacker can just use any valid certificate. In other cases, certificate checking runs into some problem, and an inexperienced developer finds a "solution" on StackOverflow to just disable certificate checking, which, again, makes TLS worthless. In other cases, a client might make a valid TLS request to the wrong server (either by mistake or due to some other attack).

With OAuth 2, any of these problems will leak your bearer token, meaning than an attacker can act as you until the token expires.

With OAuth 1, you're typically going over TLS anyway, but even if an attacker knows the contents of all requests, they won't be able to act as you because they still won't be able to sign any future requests.

Edit: I just dug up the blog post I've read that describes most of the points I made above: https://hueniverse.com/oauth-bearer-tokens-are-a-terrible-id...

Having developed apps that use TLS in many languages, this is very true for most of them. I was pleasantly surprised by the Go TLS library - it gets all of this correct by default.