What bothers me about OAuth is the way you're on one website and are then asked with a pop-up to enter your Gmail or Facebook etc. password as a normal part of the flow. Users aren't savvy enough to check the URL or understand what's going on here so getting them used to this flow is asking for phishing by the look of it. Something that forced two factor authentication would be good.
Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
111–120 of 186 posts
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#112In my opinion, having worked extensively with OAuth2 (mostly in the form of OIDC) and other modern AuthN/Z protocols, the author of this post does not truly understand OAuth 2, nor have they looked in any appropriate depth into supplements like OIDC or alternatives. For one, bearer token [1] is only one type of "Access Token" described by the OAuth2 spec [2]. In fact, the OAuth2 spec is very vague on quite a few impl…
Author here: > For one, bearer token [1] is only one type of "Access Token" described by the OAuth2 spec [2]. In fact, the OAuth2 spec is very vague on quite a few implementation details (such as how to obtain user info, how to validate an Access Token), which the author seems to just assume are part of the spec, as he does with bearer token. Other parts, like the client/user distinction, and the recommendation for s…
If we can get an app for banking, I wonder if we can ever get an app for voting. A vote would seem to be less valuable than access to an enormous sum of money, yet one is available to be instantly and the other requires standing in line.
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#113This is unnecessary. Many banks can and will enforce 2-factor authentication with their oauth flow, which sufficiently validates the client and would prevent a MITM attack. Your whole premise is surrounded by the threat a client browser would not properly validate a server certificate... come on... really?
You do know about phishing, right? There are many ways to get a user (not client) to accept an invalid cert, and some cases where a client will accept an invalid cert. They want cryptographic proof of client identity . That means somehow the client has to prove they are the real user and not an attacker who intercepted the connection somehow (which, again, is completely possible). Client certs are a way to verify wit…
That seems right to me. It's the same approach as SSH key-based auth in a nutshell
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#114One big problem with OAuth on mobile apps is this scenario. I've seen this in the wild for non security-critical apps. As far as I can tell, it's not a bug so much as it is a problem with the OAuth protocol and webview permissions: 1) MyLittleApp wants OAuth access to BankOfMars 2) MyLittleApp bundles BankOfMars SDK into MyLittleApp 3) MyLittleApp requests oauth access via SDK 4) SDK opens WebView for user to log int…
This describes the flow for a "trusted client", which is not the correct flow to use for securing this scenario. Instead, the "untrusted client" flow looks like this:
1) MyLittleApp wants OAuth access to BankOfMars
2) MyLittleApp bundles BankOfMars SDK into MyLittleApp
3) MyLittleApp registers itself with BankOfMars,
which then has sole discretion over whether
to allow it to access data hosted by BankOfMars.
5) If approved by BankOfMars, MyLittleApp can now
request oauth access to a user's data
with the BankOfMars SDK.
6) SDK opens WebView for user to approve MyLittleApp's
request to access user's data hosted by BankOfMars.
User may reject the application's request.
7) If the user approves the application's request,
the user is then prompted for authentication.
This can be in the form of a username/password,
but may also include two-factor authentication
or whatever BankOfMars deems necessary for security.
8) Should BankOfMars or the user choose to do so,
either can revoke the right of MyLittleApp
to access BankOfMars data.
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#115Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#116This is unnecessary. Many banks can and will enforce 2-factor authentication with their oauth flow, which sufficiently validates the client and would prevent a MITM attack. Your whole premise is surrounded by the threat a client browser would not properly validate a server certificate... come on... really?
2-factor authentication does not protect against that. The victim does not know they are being MITMd and enters the 2FA code.
The 2FA device from my bank (https://nl.wikipedia.org/wiki/Rabo_Scanner) shows what permission is asked: account login, signing a transaction for amount x, etc.. You might MITM it, but it would be hard to profit, because the only thing feasible seems to deflect some transaction to another account, and it would only work once and raise suspicion quickly thereafter.
The bank could encode the permission (amount, beneficiary, read access, etc with an expiration date) given into an OAuth bearer token, and the app can use the token to do exactly the things that the user consented to.
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#117I visited the homepage ( https://www.teller.io/ ) and got a warning about the SSL cert being invalid. Kind of ironic. :)
> I visited the homepage ( https://www.teller.io/ ) and got a warning about the SSL cert being invalid. Kind of ironic. :) The correct URL is https://teller.io and then you wont get an SSL cert warning. Not everyone uses "www". Nowhere on teller.io do you see a link to www. You put garbage in and got garbage out.
many if not most people input the www subdomain by rote. unless teller does not care about that category of people, it should probably fix the issue
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#118Earlier quoted context omitted.
This is why the OAuth Identity Providers that take security most seriously do not allow WebView login (or at least provide an SDK where you don't need it).
How exactly do you prevent a user agent WebView in an app from spoofing iOS Safari?
It's very hard to do but you can at least make your SDK do a fast app switch to safar rather than use a WebView. Of course evil apps can find a way around it like you said but at least you can make your SDK and Documentation point the right way,
I am not experienced with iOS but I also suspect there are more advanced WebView detection tricks. It also doesn't help that Apple really doesn't like fast app switching.
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#119Earlier quoted context omitted.
What's to stop the app (or anyone in the context of a rooted device) replacing the legit Mondo auth page with a shim? Nothing.
What does replacing the auth page gain the attacker? At worst the user enters their email address into a phishing page. The important thing is that there isn't a password :)
>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.
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#120Problem one exists because, apparently, MITM is a problem with TLS because it's possible for bogus certificates to get through? Well... I guess. But then that's a TLS problem. And your entire banking website is served through TLS. So, if it really is an issue, then solving it just for auth is like putting an Abus padlock on a screen door.
Problem two bemoans the bearer token in Oauth 2. Yes, it's not as secure as OAuth 1, but it's also far simpler. But you don't have to use bearer tokens; you are free to use MAC tokens instead. Why reinvent the wheel?