Live data from Hacker News

Why Mastercard Doesn't Use OAuth 2.0

developer.mastercard.com

31–40 of 56 posts

Re: Why Mastercard Doesn't Use OAuth 2.0

#31
post #23

Any app that takes security seriously will need to take a layered approach. So while Oauth 2, which is just a framework contrary to oauth 1.0a, seems to outsource its integrity protection to TLS this isnt enough: others have already pointed out that many companies hijack TLS at their edge proxies. Banks do this bu requirement of the regulator. So you would need additional defenses against tampering such as OpenID Con…

So I guess the alternative would be to tunnel TLS inside TLS. So they can set up fake CAs to intercept the outer TLS, but not the inner TLS, satisfying both bank regulators and actual security. Until regulators catch on and we have to go around in circles again ...

Re: Why Mastercard Doesn't Use OAuth 2.0

#32
post #4

I'm not sure I understand the concern with integrity of OAuth 2.0 payloads. Sending the request over HTTPS already ensures that the request is not tampered with, and also guards against replay attacks.

Breaking IP (e.g. MITM the server) means you get a TLS certificate anyway. This might be easier done than said[1].

Breaking IP might not even be necessary because programmers are dumb[2].

[1]: https://www.bleepingcomputer.com/news/security/dns-poisoning...

[2]: http://web.archive.org/web/20120317165131/http://forum.devel...

Re: Why Mastercard Doesn't Use OAuth 2.0

#33
post #3

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.

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 disa…

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.

Re: Why Mastercard Doesn't Use OAuth 2.0

#34

Earlier quoted context omitted.

Can't they just also require that their implementation of OAuth2 also requires a signed payload?

Sure. For example they could require you to sign the body of the HTTP request and put the signature in the HTTP "Authorization" header.

The Authorization header is where the authentication token goes. It's already used.

Re: Why Mastercard Doesn't Use OAuth 2.0

#35
post #16

Earlier quoted context omitted.

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.

Re: Why Mastercard Doesn't Use OAuth 2.0

#36
post #10
post #8

Earlier quoted context omitted.

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.

And people from that country have those certificates installed? Voluntarily?

Uyghurs in China need to install mandatory tracking app to their mobile phones.

Re: Why Mastercard Doesn't Use OAuth 2.0

#37
post #29
post #9

Earlier quoted context omitted.

This[0] paper argues that "OAuth 2.0 is intrinsically vulnerable to App impersonation attack due to its provision of multiple authorization flows and token types." [0] Application Impersonation: Problems of OAuth and API Design in Online Social Networks http://cosn.acm.org/2014/files/cosn018s-huA.pdf

The paper says that there are ways for users to find out their own access tokens and then "impersonate the app". That might be a valid threat model once the machines take over, but for now my access token identifies me and not my app.

It's always fun when people try to design publicly accessible APIs that nevertheless aren't public. Unfortunately they keep finding ways to make it happen by force.

Re: Why Mastercard Doesn't Use OAuth 2.0

#38
post #16

Earlier quoted context omitted.

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.

Not everybody's. There is whole China where the certs remain installed.

Re: Why Mastercard Doesn't Use OAuth 2.0

#39
post #16

Earlier quoted context omitted.

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.

Re: Why Mastercard Doesn't Use OAuth 2.0

#40
post #17
post #7

Earlier quoted context omitted.

They (quasi-implicitly) say that a design goal of their system is "message level security", and stress the desire for "non-repudiation", which is not provided by TLS per se.

TLS client certs are a thing

TLS certs (client or server) are only used during the handshake. After that it’s symmetric crypto, so no non-repudiation if that’s what they want. (Real non-repudiation requires a lot more than just signatures though, otherwise you could just claim that you lost control of your key).
Post reply on HN