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

11–20 of 186 posts

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

#11

Post by sjtgraham »

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…

Hey Jonas! TAuth is simpler than OAuth 2.0 and doesn't suffer the same security issues. So… why use OAuth?

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

#12

Post by kaeso »

0x0 wrote: post #4

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

Kind of. Starting from 49, the feature needs to be whitelisted per web-site. Client certificates are not anymore imported automatically, only downloaded (user action needed to load into the keystore).

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

#14

Post by jhuckestein »

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

Hey Jonas! TAuth is simpler than OAuth 2.0 and doesn't suffer the same security issues. So… why use OAuth?

The devil you know I suppose ;)

IIRC we didn't go too far down the client cert route because we're behind CloudFlare and we like it that way. Something to revisit in the future.

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

#15

Post by chatmasta »

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 into BankOfMars

5) MyLittleApp has full control over the DOM presented to the user since the WebView is technically its own.

6) MyLittleApp extracts the user's password from the DOM of the WebView

7) MyLittleApp disappears and... profit?

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

#16

Post by bgidley »

sjtgraham wrote: post #8
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.

If you can cope with OAuth you can definitely manage TAuth. The cert and private key are just opaque things you pass to any HTTP client.

I agree - but as you say OAuth also suffers from MITM weaknesses. I'm just not convinced 'plain' client certs solve that as it's very hard to distribute those securely and manage them. I guess it depends where you see these being used, if used Server to Server it's not too bad, but if pushed out mobile devices (as I suspect they will be) they are very likely to leak unless strong app protection is applied.

If you're banking on strong app protection working you really need to be notified of it's state on the server which this won't do, you need to use a securely signed message from the verification/protection libraries on the client.

That can be done by storing this key into a cryptographic whitebox and then linking using it to integrity verification.

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

#17

Post by lmm »

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

Hey Jonas! TAuth is simpler than OAuth 2.0 and doesn't suffer the same security issues. So… why use OAuth?

The three-legged flow from OAuth is widely needed. (I would agree with sticking to earlier versions that allow more specific tokens though)

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

#18

Post by mgkimsal »

gyre007 wrote: post #3

It's kinda crazy that it has taken so long for someone to actually take an initiative and attempt to make the authentication more secure. I wonder if this is a custom built solution or if Teller.io is using something like HashiCorps Vault to do the whole SSL cert dance. Either way, this looks promising.

> It's kinda crazy that it has taken so long for someone to actually take an initiative and attempt to make the authentication more secure.

Not when you consider we've all been subjected to decades of "don't write your own security!!!"

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

#20

Post by sjtgraham »

bgidley wrote: post #16
sjtgraham wrote: post #8

Earlier quoted context omitted.

If you can cope with OAuth you can definitely manage TAuth. The cert and private key are just opaque things you pass to any HTTP client.

I agree - but as you say OAuth also suffers from MITM weaknesses. I'm just not convinced 'plain' client certs solve that as it's very hard to distribute those securely and manage them. I guess it depends where you see these being used, if used Server to Server it's not too bad, but if pushed out mobile devices (as I suspect they will be) they are very likely to leak unless strong app protection is applied. If you're…

This is the first version of TAuth where only server apps are in scope. Work is already underway on the solution for Mobile… Teller will need it soon for upcoming products.
Post reply on HN