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

41–50 of 56 posts

Re: Why Mastercard Doesn't Use OAuth 2.0

#41

Post by kpil »

andor wrote: post #29
gspetr wrote: 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.

That makes sense in the bizarre backwards world where security implies security from the users.

Re: Why Mastercard Doesn't Use OAuth 2.0

#42

Post by yjftsjthsd-h »

viraptor wrote: post #39
yjftsjthsd-h wrote: post #35

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.

> since certificates are all publicly logged now. Only some of them are. All EV and some DV get published.

Didn't realize that; apparently all Symantec certs require it, and I misunderstood that as industry-wide.

Re: Why Mastercard Doesn't Use OAuth 2.0

#43

Post by nmadden »

user5994461 wrote: post #34
jsiepkes wrote: post #22

Earlier quoted context omitted.

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.

There is a (now expired) draft for sending signed HTTP requests using JWS that includes the access token as part of the signature data getting around this problem.

Edit: forgot the link https://tools.ietf.org/html/draft-ietf-oauth-signed-http-req...

Re: Why Mastercard Doesn't Use OAuth 2.0

#44

Post by gsich »

viraptor wrote: post #15
gsich wrote: post #11

Using TLS makes it acceptable to send cleartext passwords. I don't know why, seems lazy. So, I understand why Mastercard doesn't rely on that.

> TLS makes it acceptable to send cleartext passwords 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?

>What do you mean?

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.

Re: Why Mastercard Doesn't Use OAuth 2.0

#46

Post by _8j50 »

nmadden wrote: post #40
_8j50 wrote: post #17

Earlier quoted context omitted.

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).

Yes,the handshake is authenticated and can have two way non-repudiation. The symmetric crypto that follows the handshake uses secret key agreed upon during the handhake. because only the client and server know that secret,all messages encrypted with it also have non-repudiation.

I don't get your point about losing keys,is there any form of non-repudiation that does not require keeping secret material secret? Are you also neglecting the fact that revocation is a thing and TLS non-repudiation works by way of a trusted 3rd party?

Re: Why Mastercard Doesn't Use OAuth 2.0

#47

Post by dogma1138 »

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

No it can potentially ensure integrity between the a client and the first TLS hop that’s about it.

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.

Re: Why Mastercard Doesn't Use OAuth 2.0

#48

Post by nmadden »

_8j50 wrote: post #46
nmadden wrote: post #40

Earlier quoted context omitted.

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).

Yes,the handshake is authenticated and can have two way non-repudiation. The symmetric crypto that follows the handshake uses secret key agreed upon during the handhake. because only the client and server know that secret,all messages encrypted with it also have non-repudiation. I don't get your point about losing keys,is there any form of non-repudiation that does not require keeping secret material secret? Are you…

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 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.

Re: Why Mastercard Doesn't Use OAuth 2.0

#49

Post by Noumenon72 »

I think https://aaronparecki.com/oauth-2-simplified/ explains that the cryptographic signature approach (if that's what they mean by "client secret") was discarded because mobile apps and single-page Javascript apps can't maintain the confidentiality of a secret anyway.

So maybe OAuth 1.0 is only better for apps running on a server?

Re: Why Mastercard Doesn't Use OAuth 2.0

#50

Post by _8j50 »

nmadden wrote: post #48
_8j50 wrote: post #46

Earlier quoted context omitted.

Yes,the handshake is authenticated and can have two way non-repudiation. The symmetric crypto that follows the handshake uses secret key agreed upon during the handhake. because only the client and server know that secret,all messages encrypted with it also have non-repudiation. I don't get your point about losing keys,is there any form of non-repudiation that does not require keeping secret material secret? Are you…

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 use gpg signatures for non-repudiation and authentication,but they can also say "the key was compromised x weeks ago". I think there is only so much a communication protocol can do.

For where oauth2 would be used,I believe what some (like OP) want is session level authentication and non-repudiation. To say "I was really speaking to " as opposed to being able to say "Specific payloads and transactions with were really made with non-repudiability". For the latter,like you suggested, a protocol with awareness of the specific data,transactions and payloads is needed. Oauth2 and TLS are session aware not application aware.

Post reply on HN