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

151–160 of 186 posts

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

#151

Post by deathanatos »

> Most importantly using JWT tokens make it basically impossible for you to experiment with an API using cURL. A major impediment to developer experience.

Why can't a developer do exactly what you did in your second video, which is to save the JWT to a variable, and then use it in the request?

Heck, you could create a quick wrapper "jwt_curl"/"jwt_http" or something that automatically pulled in that variable…

There's two big things about this scheme that leave me confused: how do you know what the correct certificate for the client is? Do you just send it over HTTPS? But then, one of your opening premises is that we don't get TLS verification correct and are open to MitM, so this seems to contradict that, or are we hoping that "that one request won't be MitM'd", like in HSTS? (which seems fine)

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

#152

Post by e12e »

obeattie wrote: post #121
nemothekid wrote: post #119

Earlier quoted context omitted.

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

Well, the malicious application can inject a password-field, and an unsuspecting user might not realize that (s)he is giving an app/attacker the password, and not the correct third party.

User education only goes so far, this type of attack can also make a web view that traditionally asks for a TOTP one-time password code susceptible to leaking a users password, even if the normal login flow doesn't ask for that password.

[ed: note that it's pretty trivial to eg: set up hidden cameras in voting booths, if you want to spy on a few people, or perhaps have people film themselves in a voting booth - the point is rather that if most people make an effort to follow the common rules wrt. voting booths, the system is reasonably secure. And it's not trivial to make similar claims about a (presumably) centralized on-line system.]

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

#153

Post by e12e »

EGreg wrote: post #112
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…

If we can get an app for banking, I wonder if we can ever get an app for voting. A vote would seem to be less valuable than access to an enormous sum of money, yet one is available to be instantly and the other requires standing in line.

The difficulty is not secure voting, the difficulty is a secure, secret vote. So that the person that cast the vote, can't prove which way they voted ("Hey, see, I voted for you, now pay me the 10.000 USD you promised me"), that other's cant prove which way any given person voted (or indeed, prove that the vote wasn't blank) ("Put him on a black-list, he voted for $wrong candidate!").

As far as I know, secure on-line voting is still an open research question (and that's just the theoretical bit, never mind building a real, concrete system).

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

#154

Post by blazespin »

andrewstuart2 wrote: post #140
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…

> 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. What makes you say that OAuth 2 cannot guarantee privacy? I think you must have a very different definition of privacy than I'm used to if you can make this claim.

the premise is that mitm attacks are easy.

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

#155

Post by blazespin »

btown wrote: post #133
EGreg wrote: post #106

Earlier quoted context omitted.

How exactly does one do this in iOS? There is a reason that Apple only allows Safari to power WebViews. How exactly would you extract the user's password from the DOM of the WebView on a non-jailbroken device using ANY APPLE APIs if the page was legitimately loaded from https://yourdomain.com ??

If the web view is inside your app, you can inject JS easily. http://www.priyaontech.com/2014/12/native-%E2%80%93-js-bridg...

or just use custom protocol and sniff it all.

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

#156

Post by e12e »

Let me see if I understand this correctly:

1) Problem: app authors disable TLS (server) cert validation.

2) Solution: give each app author the responsibility of managing and distributing a client side certificate.

Sounds like now you have two problems? In particular, you now have to make sure that every lost/compromised certificate is added to your growing CRL? And you need app developers that demonstrably do not even have the vaguest idea how public key cryptography can be used for authentication to take responsibility for doing this? And there's still no guarantee that they won't disable certificate verification?

Did I miss anything?

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

#157

Post by dlmetcalf »

EGreg wrote: post #112
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…

If we can get an app for banking, I wonder if we can ever get an app for voting. A vote would seem to be less valuable than access to an enormous sum of money, yet one is available to be instantly and the other requires standing in line.

Nope. If you control the votes, you control the money, the laws that make it, the military (including intel services, alliances & secret police), plus the rest. You don't even need to buy a presidency then. Once you control votes, you can privilege escalate to do almost anything. There's probably nothing else we should be as truly concerned about securing properly. It's already been rigged and EXTREMELY probable it was exploited for George W. Bush's election too. Electoral security is an absolute joke and a travesty.

https://en.wikipedia.org/wiki/United_States_presidential_ele...

https://en.wikipedia.org/wiki/Premier_Election_Solutions#Con...

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

#158

Post by Navarr »

chrisrhoden wrote: post #122
iLoch wrote: post #110

Earlier quoted context omitted.

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.

Is that not a fair thing to do?

Can we not assume someone with access to a Facebook account is authentically the owner of that Facebook account for all of our intents and purposes?

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

#159

Post by zaroth »

zaroth wrote: post #130
sjtgraham wrote: post #44

Earlier quoted context omitted.

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

So I realize now at this stage you are focused on server-to-server only, in which case there's no issue with trying to deploy individual client certs to end-user devices.

Pulling a certificate via the browser is not great assuming we want a highly controlled chain of custody over the private key bytes and that these certs will expire and need to be regularly rotated. But it's not much work to build some command line tool to send a CSR off for signing, that seems reasonable for server-to-server authentication.

I wonder if you'll run into issues with various languages' HTTPS libraries not properly supporting client certificates.

It's nice to think this could all just work with the lower layer taking care of everything, but I also wonder with the shitshow that is TLS if you can even be sure the client cert validation code can really be trusted as much as an application-layer check.

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

#160

Post by chatmasta »

supergeek133 wrote: post #83
chatmasta wrote: post #59

Earlier quoted context omitted.

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.

The presence of an API key is not sufficient to verify the client loaded your SDK with the same checksum as the one you released. The client can modify the code of the SDK to perform any arbitrary logic, including bypassing integrity checks.
Post reply on HN