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

Why Mastercard Doesn't Use OAuth 2.0

developer.mastercard.com

Post reply on HN
Print view View original

21–30 of 56 posts

Re: Why Mastercard Doesn't Use OAuth 2.0

#21

Post by _8j50 »

ars wrote: post #8
simonw wrote: 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.

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

Re: Why Mastercard Doesn't Use OAuth 2.0

#22

Post by jsiepkes »

philliphaydon wrote: post #14
welder wrote: post #2

This author doesn't seem to understand basic security. OAuth1a doesn't protect from "account takeover / impersonation attacks". OAuth1a just signs requests while OAuth2 delegates that to TLS. No matter how secure the lock, someone gets the keys to the house (account takeover) they can open the door.

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.

Re: Why Mastercard Doesn't Use OAuth 2.0

#23

Post by smooc »

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 Connect. In the banking apps that I have been working with we implemented additional symmetric encryption on top of the protocol (yes obfuscating the keys) and all other kinds of small things.

I’m glad mastercard does not rely solely on TLS.

Re: Why Mastercard Doesn't Use OAuth 2.0

#26

Post by stedaniels »

_8j50 wrote: post #19
philliphaydon wrote: post #14

Earlier quoted context omitted.

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

Then it would no longer be oauth2? Standards exist to prevent deviations. How do you manage signing keys and distribute them? What signature scheme,encoding,etc... Should be used?

Playing devils advocate. Show me a half decent commercial API that doesn't specify any rules of engagement with their API. All the minutiae would be specified there.

Re: Why Mastercard Doesn't Use OAuth 2.0

#28

Post by alangpierce »

simonw wrote: 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 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...

Re: Why Mastercard Doesn't Use OAuth 2.0

#29

Post by andor »

gspetr wrote: post #9
welder wrote: post #2

This author doesn't seem to understand basic security. OAuth1a doesn't protect from "account takeover / impersonation attacks". OAuth1a just signs requests while OAuth2 delegates that to TLS. No matter how secure the lock, someone gets the keys to the house (account takeover) they can open the door.

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.

Re: Why Mastercard Doesn't Use OAuth 2.0

#30

Post by alangpierce »

welder wrote: post #2

This author doesn't seem to understand basic security. OAuth1a doesn't protect from "account takeover / impersonation attacks". OAuth1a just signs requests while OAuth2 delegates that to TLS. No matter how secure the lock, someone gets the keys to the house (account takeover) they can open the door.

> This author doesn't seem to understand basic security.

This seems like an overly broad (not to mention hurtful) way to disagree with a technical assessment.

And really, I'd say that part of "understanding basic security" is understanding that there's value in multiple layers of security. OAuth1a+TLS provides two separate defenses against impersonation attacks, while OAuth2+TLS only provides one. There are many ways that TLS can fail in practice, and only OAuth1a stops impersonation attacks if that happens.

Post reply on HN