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

41–50 of 186 posts

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

#41

Post by wslh »

amluto wrote: post #30

Some features that I think a system like this should have: 1. The client (or the device holding the authentication token, or the app, etc) should be able to maintain (on its own storage!) an audit log of all transactions it has authorized, that log should be cryptographically verifiable to be append-only (think blockchain but without all the Bitcoin connotations), and the server should store audit log hashes and veri…

> an audit log of all transactions it has authorized, that log should be cryptographically verifiable to be append-only (think blockchain but without all the Bitcoin connotations)

A blockchain related technology is overkill, you just need forward integrity: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.111...

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

#42

Post by duaneb »

atonse wrote: post #32
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.

> developers in general can't cope with managing SSL certificates I'd say the same but they've done just fine publishing anything to the App Store, which uses certs everywhere. And it was even worse the first few years.

> I'd say the same but they've done just fine publishing anything to the App Store, which uses certs everywhere.

"Just fine" is a relative term here. It's still a shit show managing them—AFAIK XCode is the only realistic option, which makes me want to remove my eyes with forks.

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

#43

Post by supergeek133 »

chatmasta wrote: post #26
pc86 wrote: post #25

Earlier quoted context omitted.

Is #6 and #7 something you've seen happen, or conjecture about what might happen if some nefarious actor manages to develop a native app that requires banking integration, gets people to download it, then gets people to plug in their banking info?

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.

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

#44

Post by sjtgraham »

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.

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

#45

Post by btilly »

The main complaint about OAuth 2.0 seems to be that bearer tokens are a bad idea. Well, you can implement OAuth 2.0 to use any kind of token you want, with any property you want. People do bearer tokens because it is easy, not because it is required.

The secondary complaint seems to be that OAuth 2.0 is a mess. That one I heartily agree with! A few years ago I wound up having to figure out OAuth 2.0 and wrote http://search.cpan.org/~tilly/LWP-Authen-OAuth2-0.07/lib/LWP... as the explanation that I wish I had to start. In the process I figured out why most of the complexity exists, and whose interests the specification serves.

The key point is this: OAuth 2 makes it easy for large service providers to write many APIs that users can securely authorize third party consumers to use on their behalf. Everything good (and bad!) about the specification comes from this fact.

In other words, it serves the need of service providers like Google and Facebook. API consumers use it because we want to access those APIs. And not because it is a good protocol for us. (It most emphatically is a mess for us!)

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

#46

Post by krooj »

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 specifically, you can require domain verification and validation as part of the client registration process, and I would expect that at a minimum when dealing with delegated access to financials.

Another alternative to this would be to perform an OOB flow, wherein the redirect URI is actually hosted on the authorization sever itself and the client can scrape the access token from the Location header.

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

#47

Post by matthewaveryusa »

amluto wrote: post #30

Some features that I think a system like this should have: 1. The client (or the device holding the authentication token, or the app, etc) should be able to maintain (on its own storage!) an audit log of all transactions it has authorized, that log should be cryptographically verifiable to be append-only (think blockchain but without all the Bitcoin connotations), and the server should store audit log hashes and veri…

1. Is an awesome idea. Will it work for the tail-end of the log where most maliciousness will occur? The scenario I see is the hacker grabbing the log, and appending transactions to its copy of the log. When you go to contest those transactions, the bank will have a longer log than what your client has. Don't get me wrong there's a lot of use-cases for this: You received a confirmation that a transaction was cancelled but the bank said it didn't happen: In this case you have proof through the signed log that in fact it did happen.

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

#48

Post by thallium205 »

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?

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

#49

Post by andrewstuart2 »

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

> Shared secrets mean no non-repudiation.

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.

> Most importantly using JWT tokens make it basically impossible for you to experiment with an API using cURL.

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.

> OAuth 2.0 is simply a security car crash from a bank's perspective. They have no way to prove that an API transaction is bona fide, exposing them to unlimited liability.

TL;DR: This article, led by comments like this ("unlimited", really?), strikes me as pure marketing (aimed at a naive audience) for a "spec" that probably would not exist had proper due diligence into alternatives, or perhaps some public discussion, occurred. At the very least, inconsistencies (a few of which I've mentioned above) could have been avoided.

[1] https://tools.ietf.org/html/rfc6750 [2] https://tools.ietf.org/html/rfc6749 [3] https://tools.ietf.org/html/rfc6749#section-2.3.2

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

#50

Post by ForHackernews »

> One of the biggest problems with OAuth 2.0 is that it delegates all security concerns to TLS but only the client authenticates the server (via it's SSL certificate), the server does not authenticate the client. This means the server has no way of knowing who is actually sending the request.

That's not just plain not true. In the OAuth2 authorization_code grant, a "confidential" client is REQUIRED to send a client_id and client_secret to authenticate itself to the server.

https://tools.ietf.org/html/rfc6749#section-4.1.3

> If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1.

Now, this doesn't work for "public" clients like a pure-javascript webapp, but that's a separate question.

Count me as pretty dubious of letting some unknown group try to re-implement bank authentication without fully understanding the specification they're trying to fix.

Post reply on HN