Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.teller.io

Post reply on HN
Print view View original

121–130 of 186 posts

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

#121

Post by obeattie »

nemothekid wrote: post #119
jhuckestein wrote: post #36

Earlier quoted context omitted.

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.

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

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

#122

Post by chrisrhoden »

iLoch wrote: post #110
JoshMandel wrote: post #53

1. To my mind, the fundamental problem OAuth solves is "letting a user decide" to share data with an app, without making the user responsible for jumping back and forth between the app and her API provider (her bank, in this case). OAuth holds the user's hand through a series of redirects, and the user doesn't have to copy/paste tokens, or remember where she is in the flow, or know what comes next. Does TAuth have a…

I disagree with your first point. The fundamental problem OAuth solves is secure authentication. OAuth 2.0 provides this at a bear minimum as it can be broken in any way SSL/TLS can be broken. The argument the author is making is that this level of security is not sufficient for a bank. I think I agree with this statement. For general use, OAuth 2 provides a sufficient level of security since the platforms that use i…

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.

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

#123

Post by mderazon »

amgreg wrote: post #117
levemi wrote: post #64

Earlier quoted context omitted.

> 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

Of course they should. Redirect traffic from www.teller.io to teller.io

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

#125

Post by blazespin »

chatmasta wrote: post #15

One 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…

yeah, we need some kind of email version of oauth - where the id provider emails a link for the user to click on to authn and approve the auth code to go to the client app. it's a bit weaker UX, but your described scenario is a massive gaping hole.

mmm, thinking about it, might be compatible with the current spec.

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

#127

Post by blazespin »

EGreg wrote: post #108
habosa wrote: post #85

Earlier 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?

you email the authn link to the user rather than use openurl

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

#128

Post by uncleyo »

andrewstuart2 wrote: post #109
sjtgraham wrote: post #82

Earlier quoted context omitted.

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…

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 identify the client but not sure you can ever identify app developer with it (if needed for audit purposes). Or am I missing something, maybe?

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

#129

Post by defiancedigital »

I didn't see anything about renegotiation. If clients present their certificates during first handshake, it will lead to security concerns. Attackers could observe client's certificates (extract meta-data, de-ano clients ...). If renegotiation is used it will drastically reduce "Bonus DDOS mitigation"

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

#130

Post by zaroth »

sjtgraham wrote: post #44
zaroth wrote: post #39

The premise for adding client certificates is a MITM made possible because careless app developers will disable server certificate validation. So, how exactly does adding a client certificate solve that problem? If server certificate validation is disabled on the client, the MITM can still accept the client certificate and substitute their own. The difference is that in this case the attacker will gain access to the…

Actually no. The certificate must be signed by Teller (or it's rejected) and associated with the same application as the auth token.

Right, so what stops an attacker from getting a client certificate signed by Teller?

I guess I missed something about how the client certificate is being provisioned. I see the video showing a client certificate being downloaded onto a desktop, but that's obviously not the intended UX for actual end-users...?

Post reply on HN