7 ms·

Why Mastercard Doesn't Use OAuth 2.0

144 points by hitr 8y ago

welder 8y ago
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.
- lwf 8y ago
  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.
  - badrabbit 8y ago
    TLS client certs are a thing
    - deleted 8y ago
      [deleted]
    - nmadden 8y ago
      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).
      - badrabbit 8y ago
        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?
        nmadden 8y ago
        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.
        badrabbit 8y ago
        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 <other end>" as opposed to being able to say "Specific payloads and transactions with <other end> 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.
        nmadden 8y ago
        Right. Most applications and protocols only need authentication. Non-repudiation is kind of an extreme security property, rarely needed outside of legal/financial transactions.
- gspetr 8y ago
  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 http://cosn.acm.org/2014/files/cosn018s-huA.pdf
  - andor 8y ago
    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.
    - plattegrond 8y ago
      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.
    - kpil 8y ago
      That makes sense in the bizarre backwards world where security implies security from the users.
- philliphaydon 8y ago
  Can't they just also require that their implementation of OAuth2 also requires a signed payload?
  - badrabbit 8y ago
    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?
    - stedaniels 8y ago
      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.
    - dwaite 8y ago
      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.
  - jsiepkes 8y ago
    Sure. For example they could require you to sign the body of the HTTP request and put the signature in the HTTP "Authorization" header.
    - user5994461 8y ago
      The Authorization header is where the authentication token goes. It's already used.
      - nmadden 8y ago
        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-request-03 https://tools.ietf.org/html/draft-ietf-oauth-signed-http-req...
- alangpierce 8y ago
  > 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.
simonw 8y ago
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.
- lwf 8y ago
  From a technical PoV, it feels like it is easier to argue after the fact "look, you sent this message, you signed it", v.s. "trust us, all comms were over TLS, we promise our logs are accurate and your token was not leaked".
- ars 8y ago
  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.
  - gsich 8y ago
    And people from that country have those certificates installed? Voluntarily?
    - viraptor 8y ago
      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.
      - yorwba 8y ago
        Also, if the country has its own root CA, it can just sign arbitrary certificates. https://en.wikipedia.org/wiki/CNNIC#Fraudulent_certificates https://en.wikipedia.org/wiki/CNNIC#Fraudulent_certificates
narsil 8y ago
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.
- bootloop 8y ago
  Wouldn't this be a reasonable reason if you consider that they might use additional equipment to terminate HTTPS connection in an early layer of their network?
- gsich 8y ago
  no. You don't know where the TLS terminates.
- geocar 8y ago
  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-or-bgp-hijacking-suspected-behind-trezor-wallet-phishing-incident/ https://www.bleepingcomputer.com/news/security/dns-poisoning... [2]: http://web.archive.org/web/20120317165131/http://forum.developers.facebook.net/viewtopic.php?pid=258460 http://web.archive.org/web/20120317165131/http://forum.devel...
- dogma1138 8y ago
  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.
gsich 8y ago
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.
- viraptor 8y ago
  > 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?
  - ge0rg 8y ago
    The problems are before and after the TLS tunnel. 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.
  - gsich 8y ago
    >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.
smooc 8y ago
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.
- ploxiln 8y ago
  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 ...
alangpierce 8y ago
Related: here's a write-up from one of the OAuth 2 authors on the problems he sees in OAuth 2 and why he thinks OAuth 1 is better: https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529 https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45...
EGreg 8y ago
I once asked a related question on StackOverflow https://security.stackexchange.com/questions/161734/why-does-oauth-and-oauth-2-have-access-tokens-at-all https://security.stackexchange.com/questions/161734/why-does...
jacksmith21006 8y ago
Curious how many have moved from LDAP to using OAuth? Would seem the future for enterprise will be OAuth.
Noumenon72 8y ago
I think https://aaronparecki.com/oauth-2-simplified/ 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?
dwaite 8y ago
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.
starptech 8y ago
The problems reminds me of https://github.com/hueniverse/oz/ https://github.com/hueniverse/oz/ it's from one of the former oauth guys.
woranl 8y ago
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.

144 points by hitr 8y ago

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.

lwf 8y ago
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.
- badrabbit 8y ago
  TLS client certs are a thing
  - deleted 8y ago
    [deleted]
  - nmadden 8y ago
    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).
    - badrabbit 8y ago
      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?
      - nmadden 8y ago
        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.
        badrabbit 8y ago
        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 <other end>" as opposed to being able to say "Specific payloads and transactions with <other end> 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.
        nmadden 8y ago
        Right. Most applications and protocols only need authentication. Non-repudiation is kind of an extreme security property, rarely needed outside of legal/financial transactions.
gspetr 8y ago
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 http://cosn.acm.org/2014/files/cosn018s-huA.pdf
- andor 8y ago
  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.
  - plattegrond 8y ago
    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.
  - kpil 8y ago
    That makes sense in the bizarre backwards world where security implies security from the users.
philliphaydon 8y ago
Can't they just also require that their implementation of OAuth2 also requires a signed payload?
- badrabbit 8y ago
  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?
  - stedaniels 8y ago
    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.
  - dwaite 8y ago
    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.
- jsiepkes 8y ago
  Sure. For example they could require you to sign the body of the HTTP request and put the signature in the HTTP "Authorization" header.
  - user5994461 8y ago
    The Authorization header is where the authentication token goes. It's already used.
    - nmadden 8y ago
      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-request-03 https://tools.ietf.org/html/draft-ietf-oauth-signed-http-req...
alangpierce 8y ago
> 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.

simonw 8y ago

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.

lwf 8y ago
From a technical PoV, it feels like it is easier to argue after the fact "look, you sent this message, you signed it", v.s. "trust us, all comms were over TLS, we promise our logs are accurate and your token was not leaked".
ars 8y ago
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.
- gsich 8y ago
  And people from that country have those certificates installed? Voluntarily?
  - viraptor 8y ago
    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.
    - yorwba 8y ago
      Also, if the country has its own root CA, it can just sign arbitrary certificates. https://en.wikipedia.org/wiki/CNNIC#Fraudulent_certificates https://en.wikipedia.org/wiki/CNNIC#Fraudulent_certificates

narsil 8y ago

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.

bootloop 8y ago
Wouldn't this be a reasonable reason if you consider that they might use additional equipment to terminate HTTPS connection in an early layer of their network?
gsich 8y ago
no. You don't know where the TLS terminates.
geocar 8y ago
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-or-bgp-hijacking-suspected-behind-trezor-wallet-phishing-incident/ https://www.bleepingcomputer.com/news/security/dns-poisoning... [2]: http://web.archive.org/web/20120317165131/http://forum.developers.facebook.net/viewtopic.php?pid=258460 http://web.archive.org/web/20120317165131/http://forum.devel...
dogma1138 8y ago
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.

gsich 8y ago

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.

viraptor 8y ago
> 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?
- ge0rg 8y ago
  The problems are before and after the TLS tunnel. 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.
- gsich 8y ago
  >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.

smooc 8y ago

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.

ploxiln 8y ago
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 ...

alangpierce 8y ago

Related: here's a write-up from one of the OAuth 2 authors on the problems he sees in OAuth 2 and why he thinks OAuth 1 is better: https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529 https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45...

EGreg 8y ago

I once asked a related question on StackOverflow https://security.stackexchange.com/questions/161734/why-does-oauth-and-oauth-2-have-access-tokens-at-all https://security.stackexchange.com/questions/161734/why-does...

jacksmith21006 8y ago

Curious how many have moved from LDAP to using OAuth? Would seem the future for enterprise will be OAuth.

Noumenon72 8y ago

I think https://aaronparecki.com/oauth-2-simplified/ 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?

dwaite 8y ago

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.

starptech 8y ago

The problems reminds me of https://github.com/hueniverse/oz/ https://github.com/hueniverse/oz/ it's from one of the former oauth guys.

woranl 8y ago

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.