Live data from Hacker News

Why Mastercard Doesn't Use OAuth 2.0

developer.mastercard.com

51–56 of 56 posts

Re: Why Mastercard Doesn't Use OAuth 2.0

#51
post #50
post #48

Earlier quoted context omitted.

Non-repudiation means that the party that sent a message cannot later deny having sent it. In TLS both sides negotiate a shared secret key(s) that they then use for fast symmetric crypto for the actual messages. Symmetric because both sides know the same keys. This means that after the fact either side can claim that the other side fabricated messages that apparently came from them, because they could have done. The…

I now understand your first point. > The point about losing keys is that if I can plausibly claim that I “lost” control of my key then I can claim that an imposter signed a message that apparently came from me. So even with digital signatures you usually need additional controls (hardware, processes, legal/regulatory etc) to really guarantee non-repudiation. Depends on the use-case right? For example,foss projects us…

Right. Most applications and protocols only need authentication. Non-repudiation is kind of an extreme security property, rarely needed outside of legal/financial transactions.

Re: Why Mastercard Doesn't Use OAuth 2.0

#52
post #19

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?

What they are doing is no longer OAuth 1, since they require a hash of the body as a parameter for input into the OAuth 1 signature/MAC.

Re: Why Mastercard Doesn't Use OAuth 2.0

#53
They did this to provide message-level integrity. OAuth 2 switched to Transport-level confidentiality/Integrity.

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.

Re: Why Mastercard Doesn't Use OAuth 2.0

#54

Earlier quoted context omitted.

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.

And how is that accomplished? I doubt this will happen on private PCs.

Re: Why Mastercard Doesn't Use OAuth 2.0

#56
It’s unfortunate that Big companies are pushing for OAuth 2.0 and trying to blindsided developers as if OAuth 2.0 is an upgrade to OAuth 1.0a. It is not! OAuth 1.0a provides authenticity, integrity, and non-repudiation. Something that OAuth 2.0 cannot match.
Post reply on HN