Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it • Hacker News Board

Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it

#161

Post by comex » Fri, May 06, 2016, 1:43 AM UTC

sandGorgon wrote: post #95

obeattie wrote: post #27

Earlier quoted context omitted.

The flow we (Mondo) are considering for this: 1. MyLittleApp opens web view to log into Mondo 2. User enters something to identify themselves into the web view (eg. email address, phone number) 3. We dispatch a notification to the user's registered device (ie. the Mondo app where the user is logged in – this may be the same device or a different device) 4. User opens the Mondo app and accepts/rejects the authorisatio…

This is unnecessary - if you are assuming that people will have Mondo app already, then the SDK will simply trigger an intent to open the app. The reason webviews are present in the SDK is because of the possibility that your app is not installed. You cannot depend on SMS pin without your app, because that can be spoofed. I don't see any option except for manual pin copy paste from the app to a well known website tha…

SMS spoofing is a problem if the flow depends on the user sending an SMS, and generic impersonation (by the client app) is a problem if users have to do something like click a link in the SMS and enter a password. But if a phone number is already associated with the account, and the only SMS is one from the service to the user containing a randomly generated login code, it should be safe, no? At least, that's the flow everyone and their dog seems to use these days.

Of course, that doesn't work without a phone.

Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it

#162

Post by sandGorgon » Fri, May 06, 2016, 3:15 AM UTC

comex wrote: post #161

sandGorgon wrote: post #95

Earlier quoted context omitted.

This is unnecessary - if you are assuming that people will have Mondo app already, then the SDK will simply trigger an intent to open the app. The reason webviews are present in the SDK is because of the possibility that your app is not installed. You cannot depend on SMS pin without your app, because that can be spoofed. I don't see any option except for manual pin copy paste from the app to a well known website tha…

SMS spoofing is a problem if the flow depends on the user sending an SMS, and generic impersonation (by the client app) is a problem if users have to do something like click a link in the SMS and enter a password. But if a phone number is already associated with the account, and the only SMS is one from the service to the user containing a randomly generated login code, it should be safe, no? At least, that's the flo…

The problem is hidden in what you wrote.

> and the only SMS is one from the service to the user

There is zero possibility of a customer actually recognizing a phone number...or even a shortcode. Assume that whatever SMS comes in your phone is going to be trusted by users. However the one thing that people will know how to do is Google their banks name and go to the corresponding website.

Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it

#163

Post by sandGorgon » Fri, May 06, 2016, 3:17 AM UTC

obeattie wrote: post #98

sandGorgon wrote: post #95

Earlier quoted context omitted.

This is unnecessary - if you are assuming that people will have Mondo app already, then the SDK will simply trigger an intent to open the app. The reason webviews are present in the SDK is because of the possibility that your app is not installed. You cannot depend on SMS pin without your app, because that can be spoofed. I don't see any option except for manual pin copy paste from the app to a well known website tha…

The user may be on a desktop, or a different device. We want to support such flows too. I agree in the "native app on same device" situation, we can bypass all this by bouncing straight to our app though.

You misunderstand. I'm not advocating for an app only flow. I'm suggesting that your own flow is restricted to work well only if the Mondo app is preinstalled ... In which case your flow is useless anyway.

I think you should talk about the case when a customer does not have Mondo app installed and another app asks for authorization to access. How will the auth flow work.

Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it

#164

Post by sandGorgon » Fri, May 06, 2016, 3:22 AM UTC

obeattie wrote: post #121

nemothekid wrote: post #119

Earlier quoted context omitted.

> What does replacing the auth page gain the attacker? If the spoof app has a "Connect with Twitter* (and you don't have the Twitter app installed), and then a webview is opened, the spoof app can replace Twitter's login page with their own, and capture the username and password.

In the proposed implementation above, the _only_ piece of information that a user enters inside the web view is a username. The user must then use the native Mondo app on a previously-authenticated device to complete the OAuth flow. The Mondo app could also require biometric (ie. Touch ID) authentication. While a malicious application can inject JavaScript to intercept the username, this alone is useless to an attack…

As I mentioned earlier..this is predicated on the user having installed a Mondo app. That is not workable.

You must have a flow where this works without your app being installed.

Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it

#165

Post by zanny » Fri, May 06, 2016, 3:23 AM UTC

Navarr wrote: post #158

chrisrhoden wrote: post #122

Earlier quoted context omitted.

Nope, authorization. Authentication is left as an exercise for the implementer. Some people use the ability to be authorized to access an account on e.g. Facebook as a stand-in for authentication, but that's a different issue.

Is that not a fair thing to do? Can we not assume someone with access to a Facebook account is authentically the owner of that Facebook account for all of our intents and purposes?

Authentication is to prove who you are - authorization is to just have permission to do something, as a subset of authenticated rights.

You would generally be much less rigorous in the Facebook example between giving someone access to your shared photo albums than to your account settings. Having an oauth token does not make you signed into Facebook at all, but just says that you have valid rights to do something.

Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it

#166

Post by mfjordvald » Fri, May 06, 2016, 3:30 AM UTC

Navarr wrote: post #158

chrisrhoden wrote: post #122

Earlier quoted context omitted.

Nope, authorization. Authentication is left as an exercise for the implementer. Some people use the ability to be authorized to access an account on e.g. Facebook as a stand-in for authentication, but that's a different issue.

Is that not a fair thing to do? Can we not assume someone with access to a Facebook account is authentically the owner of that Facebook account for all of our intents and purposes?

As it is right now, yes. But imagine a scenario where Facebook might implement a child account where a parent has access to monitor the usage.

Now there are two people with authorisation to access this Facebook account so the process no longer unique authenticates a single individual.

Of course this is a contrived example and I'm sure there are better examples. But this is why OAuth is authorisation and not authentication and why something like OpenID Connect exists on top of OAuth2.

Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it

#167

Post by EGreg » Fri, May 06, 2016, 4:23 AM UTC

cakoose wrote: post #147

EGreg wrote: post #103

Actually oAuth 1.0 is less secure than oAuth 2.0 because it engages in security theater. It doesn't even require https and as a result any man in the middle can eavesdrop on the requests. And if the token is leaked, it's game over.

oAuth 1.0 supports both PLAINTEXT and HMAC-based signature schemes. I assume the article is assuming HMAC-based signatures (the PLAINTEXT option seems to be less well-known). With an HMAC-based signature, the token will not be leaked. But you're correct that eavesdropping is possible.

Right, the HMAC based approach is what is recommended over the bearer token approach. But you still leak everything else in the request.

Actually, the same logic should be done for cookies. You COULD replace cookies (which are bearer tokens) with signing every request to the server, but then you're just avoiding the REAL solution: https!

Actually the biggest security theater I have seen on the web is httponly cookies to "mitigate XSS". As if the main thing an attacker will do once they inject JS is to send your cookies somewhere. They can just execute anything in the context of your session while they still have it! So by being security theater, httponly cookies are worse than useless. The right way is to prevent XSS by escaping everything properly.

Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it

#168

Post by hueving » Fri, May 06, 2016, 5:13 AM UTC

sandGorgon wrote: post #162

comex wrote: post #161

Earlier quoted context omitted.

SMS spoofing is a problem if the flow depends on the user sending an SMS, and generic impersonation (by the client app) is a problem if users have to do something like click a link in the SMS and enter a password. But if a phone number is already associated with the account, and the only SMS is one from the service to the user containing a randomly generated login code, it should be safe, no? At least, that's the flo…

The problem is hidden in what you wrote. > and the only SMS is one from the service to the user There is zero possibility of a customer actually recognizing a phone number...or even a shortcode. Assume that whatever SMS comes in your phone is going to be trusted by users. However the one thing that people will know how to do is Google their banks name and go to the corresponding website.

The customer doesn't need to know the number, that's the point. The only sensitive info is what is being sent, so there is absolutely nothing to gain by spoofing a number and sending junk to the user.

It's like me telling you I'm going to email you the passcode to a gate. If Bob overhears this and knows your email and my email, he still isn't in a position to do anything if he can spoof emails. Best case is he sends you the wrong code and you don't get access until you get the real code from me.

Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it

#169

Post by sandGorgon » Fri, May 06, 2016, 5:35 AM UTC

hueving wrote: post #168

sandGorgon wrote: post #162

Earlier quoted context omitted.

The problem is hidden in what you wrote. > and the only SMS is one from the service to the user There is zero possibility of a customer actually recognizing a phone number...or even a shortcode. Assume that whatever SMS comes in your phone is going to be trusted by users. However the one thing that people will know how to do is Google their banks name and go to the corresponding website.

The customer doesn't need to know the number, that's the point. The only sensitive info is what is being sent, so there is absolutely nothing to gain by spoofing a number and sending junk to the user. It's like me telling you I'm going to email you the passcode to a gate. If Bob overhears this and knows your email and my email, he still isn't in a position to do anything if he can spoof emails. Best case is he sends…

The problem we are attempting to solve is that a third party app is demanding access to your bank account, but you only want to enter your password on the bank page. So the trust that needs to be establishmed, is that a page (being shown by the app through webview) is a genuine bank page and you can go ahead and put in your password there.

Bob is impersonating you in the first place and asking for the password. How do I know whether it is you or him?

Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it

#170

Post by ForHackernews » Fri, May 06, 2016, 7:11 AM UTC

uncleyo wrote: post #128

andrewstuart2 wrote: post #109

Earlier quoted context omitted.

My DH comment was a bit aside the point I probably should have made. (Also, apologies for my sarcasm re: bash pipes -- that was unnecessary and probably unproductive). > Public key cryptography can be used with JWT tokens but they don't solve the problem of how the client will generate key pairs, demonstrate proof of possession of the private key, and enrol the public key with the API. JWT is not in any way attemptin…

I completely agree with everything you said and know a bit about OIDC too, but since I'm far from mobile/3rd party apps development, there is one thing I don't understand: client credentials (confidential client) in case of mobile app installed from the marketplace. How is it done? You'd need dynamic client registration, right? I know there's a spec for that and I think I understand the mechanics. That would let you…

The official recommendations for native apps are here: https://tools.ietf.org/html/draft-ietf-oauth-native-apps-01

They suggest using PKCE (challenge-repsonse) https://tools.ietf.org/html/rfc7636 to authenticate clients that can't be trusted with a client secret.