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

81–90 of 186 posts

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

#81

Relying on SMS for bank security has always seemed crazy to me. It's not secure. Didn't Telegram creator just got hacked by the Russian mobile provider that sent an SMS to itself?

A lot of banks do use proper hardware tokens (TOTP and similar) for all transactions though.

I am under the impression that we are now in a phase where security needs to be stepped up, but in the mean time tokens send via SMS are considered 'good enough'. There are lots of initiatives for the next step, each providing proper two-factor authentication, but a lot of services are waiting it out because the hardware tokens or smartcards you need for each user cost money, and if you adopt one of the current solutions such as TOTP tokens, users would need such a device for each service they use (again, for banks this is already accepted; at least in the Netherlands).

Ideally, a standard such as FIDO U2F gains ground, so users can safely and conveniently reuse a single hardware token for any service supporting that standard. Who knows, perhaps having your 'internet key' on you can become as commonly accepted as having your house keys on you.

Also, relying on SMS means all these services have a single unique number to identify you with across services. I dislike the privacy implications this entails, and prefer to keep (some of) my on-line identities neatly quarantined the rest. FIDO U2F addresses this problem; even if you use the same hardware key for every service you use, they cannot be linked.

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

#82

In 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 separate validation of clients, the author ignores completely, generating his own (ironically mostly OAuth2-compliant [3]) spec.

Last time I checked other access token types were still drafts and bearer tokens were the only stable kind.

> Again, not true. Diffie-Hellman provides a great way to come to a shared secret that you can be cryptographically sure (the adversary's advantage is negligible) is shared between you and a single verifiable keyholder.

I as a bank cannot attribute liability for an erroneous transaction to a developer if with both share the secret with which a signature is computed. If I as a bank am compromised and want to cover my arse by moving the blame to a poor external developer I can do that with a shared secret by forging signatures after the fact. This is precisely why I don't want shared secrets.

Even if your point is valid re DH, why push that up to the application level and reinvent the wheel when you can get the same benefits, less intrusively by using a battle tested protocol circa 20 years old?

> sigh. If only there was a way to write one orthogonal program that can speak HTTP, and in a single cli command send that program's output to another program that can understand the output. Maybe we could call it a pipe. And use this symbol: |. If only.

This is shit developer experience. Why bother with a Rube Goldberg sequence of piped commands when you can just curl?

Finally, despite everything you say no OAuth 2.0 based protocol can guarantee privacy. People like that privacy when it comes to their finances I find.

Sorry for any typos, I'm on the move. Thanks for your comments :)

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

#83

Earlier quoted context omitted.

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

It depends if that SDK has an API key barrier or not. I mean if I'm providing 3rd party access, I want to see how each individual app is performing and what it is doing.

But yes, aside from that potential difference, I understand what you're saying.

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

#85

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…

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

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

#86

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

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

#87
post #64
post #55

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

[deleted]

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

#89

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

>This is shit developer experience. Why bother with a Rube Goldberg sequence of piped commands when you can just curl?

For which developers?

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

#90
post #60

Earlier quoted context omitted.

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.

Yes, but browsers design goal is to allow educated users to distinguish fake and legitimate sites (URL bar should never be forgeable). With mobile apps, the app can display anything and there is no way for even well educated user to recognize forgeries.

I think that's Android/iOS responsability.
Post reply on HN