https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45...
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.
Some countries do so as well, for example Kazakhstan and China.
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...
You don’t know which client it actually came from and you can’t ensure integrity within the transaction flow of your app.
Say the request terminated at a LB proxy then passed through and API gateway into an MQ then goes through multiple servers you need some form of integrity checking for the request and OAUTH 2.0 doesn’t provide it.
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...
It's worth noting that message-level integrity was not a design goal of OAuth 1; it is was a consequence of being based on OpenID 1/2, which were explicitly meant to run on HTTP without TLS so that they could be adopted by blogs. This was pre SNI, and pre cheap certs, so requiring HTTPS increased the hosting cost of a blog by an order of magnitude.
When the constraints changed such that requiring HTTPS was feasible, it greatly simplified OAuth. Some of these simplified proposals for OAuth became the input for OAuth 2 (where complexity was subsequently added back in the form of variants to support new use cases).
Relying on message level integrity in a protocol where such a thing was basically a side-effect of avoiding hosting costs would make me very nervous.
The clearest issue I can point to is that there is no response message integrity in MasterCard's system - an intermediary can block requests to MasterCard and give back fraudulent responses (yes, of course that payment went through!). This throws a ton of application-dependent security considerations into the system.
So, I understand why Mastercard doesn't rely on that.
What do you mean? There exists a NULL cipher, but it needs to be agreed on by both sides. If mastercard doesn't allow NULL, you can't send anything in cleartext. Or did you think of something else?
I've seen a BigCorp load balancer / web firewall log the first 1KB of each HTTP POST body into a permanent archive. A typical login submission is much smaller than that. Also in some networks the TLS connection is terminated by a frontend server and backend communication is plaintext HTTP.
While these examples are obviously bad practice, having your requests signed and not leak user passwords would easily nullify their impact.
Login with user/password. Now the receiving end knows your plaintext password. It might get hashed, but you don't know when. Twitter I think had the latest failure with that, logging the password.
TLS is just that no MITM can see the data and that you can somewhat verify who you are connecting too.
So maybe OAuth 1.0 is only better for apps running on a server?
https://security.stackexchange.com/questions/161734/why-does...
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.
Would seem the future for enterprise will be OAuth.
