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

51–60 of 186 posts

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

#51

Post by sjtgraham »

krooj wrote: post #46

Their description of the MITM attack is entirely dependent upon how the authorization server validates redirects in the implicit and authorization code grant flows. This is tied to how client registration is performed. So, if you want to ensure that the authorization code or access token is only delivered to a redirect URI that is trusted, that should be part of the policy enforced in your infrastructure... More spec…

These are two separate things: MITM and open redirect. A MITM attack is not on the the auth code, but on the bearer token.

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

#53

Post by JoshMandel »

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 similar capability? The blog post mentions "User Tokens" in passing, but doesn't define or describe them.

2. OAuth 2.0 is published as an RFC from IETF. It may be a bear to read (and yes, it's a framework rather than a protocol!), but the spec is open, easy to find, and carefully edited (https://tools.ietf.org/html/rfc6749). Is TAuth meant as a specification, or a one-off API design? If it's a specification, has there been an attempt to write it down as such?

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

#54

Post by [deleted] »

jhuckestein wrote: post #10

As much as I love Stevie, teller.io and this demo: Why not both? OAuth 2 is not "bad" in general, you just need to consider the implications of using it. If you have an API that allows clients to move customers' money or take out loans, you should take additional steps to defend against MITM attacks. For example using client side certificates :) That said, TAuth looks really good and tidy. Of course the developer may…

[deleted]

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

#56

Post by yodasan »

So, it seems like the main concern here is that a client will not validate the SSL certificate, so the SSL layer is now manually added into javascript code using the WebCrypto API to prevent this? I see not validating SSL certificates being a potential problem with something like a REST API, but is it common to disable SSL verification at the browser level where you would need to use javascript to do this?

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

#57

Post by komali2 »

gyre007 wrote: post #5
bgidley wrote: post #2

This is unlikely to work - developers in general can't cope with managing SSL certificates. They won't know what to do with them or handle them securely. You need full integrity verification, with a secure store and whitebox crypto keys to make such a scheme secure.

I gathered the target group are developers. Devs should be capable of dealing with this if they want higher security.

This illustrates a question for my I've been wondering for a while - while each developer on a project should have a good idea of security best practice, is it worth it for each to be an expert in security? I've always felt that there should be a member (or team, depending on project scale) for each project who is a "security expert" and can guide decisions for security best practice. So the developers can be aware that they need to tie in an API key at some point, and the security expert can guide the best way to implement that.

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

#58

Post by j_s »

0x0 wrote: post #4

I thought client certificates were being phased out, didn't Chrome just remove the html tag?

Recently I've heard rumblings that HTTP/2 somehow doesn't support client certificates. Can anyone point me to more information on this issue?

https://news.ycombinator.com/item?id=11556762

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

#59

Post by chatmasta »

supergeek133 wrote: post #43
chatmasta wrote: post #26

Earlier quoted context omitted.

I've seen DOM manipulation in the wild for other purposes (e.g. clickjacking for sending invites to friends). Beyond that, mostly speculation, yes. But there's nothing preventing the DOM hijacking from grabbing the password right out of the field. (Unless there's some HTML5 permissions on those fields that I'm unaware of, certainly possible).

The other thing here IMO is if I'm a bank, and I have a 3rd party app making OAuth requests... I'll want to verify code before mass release. Or at least limit the amount of bearer tokens issued without approval (Nest does this for example). Someone should internally want to review code, especially for a bank.

As a bank, if you provide an SDK for 3rd party developers to use, you are not in a position to review the app before release. Only Apple/Google gets to see that code.

The proper solution would be either 1) the ability to register 3rd party libraries with apple and require some kind of integrity check before approval (but even then, the 3rd party app could override library methods at runtime), or 2) code signing the binary blob library separately for every 3rd party developer (but then the problem is enforcement of where developers get the library from -- how do you verify SDK integrity from the bank server side?)

The fundamental problem is that, as soon as you give 3rd party developers the ability to natively integrate with your service via an SDK in their own app, you are playing a cat and mouse game.

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

#60

Post by baby »

sjtgraham wrote: post #31
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…

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.

Yup. That's every app's problem though. I can also create a webpage and design a fake "bank login" inside of it to make you enter your credentials there. There is nothing you can do about that other than educating the user.
Post reply on HN