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

31–40 of 186 posts

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

#31

Post by sjtgraham »

obeattie wrote: post #27
chatmasta wrote: post #15

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…

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.

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

#32

Post by atonse »

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.

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

#33

Post by 0xdeadbeefbabe »

> The most realistic threat is the client developer not properly verifying the server certificate, i.e. was it ultimately signed by a trusted certificate authority?

From an attackers point of view, this sounds like a very tiny ray of hope. It sounds like a cool feature/vulnerability that will probably be going away soon because it is so easy to fix.

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

#34

Post by chatmasta »

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.

Ok, so in that case the malicious app is able to steal your password... but if login requires two factor auth, the password is useless without also having access to SMS (or whichever 2fa solution) on the associated device.

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

#35

Post by sjtgraham »

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…

> the bank will know the client private keys

No one knows the private key other than the creator, in this case the developer.

> Direct support for non-repudiable signatures on the transactions themselves. Unless I'm misunderstanding what the client certs are doing in this protocol, TAuth seems to give non-repudiation on the session setup but not on the transactions themselves.

There is nothing stopping the API provider enforcing layer 7 signatures too, it's an application concern. The same private key can be used to compute those signatures or as X.509 certs can embed arbitrary public keys, you can choose another one for transaction signatures.

> Is that actually correct as written or did you mean "to a given user"?

The first version of TAuth is for Server to server apps. In this case it means developer. I will clarify that in the post. Thanks.

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

#36

Post by jhuckestein »

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.

What does replacing the auth page gain the attacker? At worst the user enters their email address into a phishing page. The important thing is that there isn't a password :)

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

#39

Post by zaroth »

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 API but the client will not, unless they are being actively MITM. If the client tries to access the API outside the MITM their client cert will be rejected as invalid.

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

#40

Post by riskable »

0xdeadbeefbabe wrote: post #33

> The most realistic threat is the client developer not properly verifying the server certificate, i.e. was it ultimately signed by a trusted certificate authority? From an attackers point of view, this sounds like a very tiny ray of hope. It sounds like a cool feature/vulnerability that will probably be going away soon because it is so easy to fix.

The problem with the, "was it signed by a trusted authority?" concept is that you generally can't automated the 3rd party since they're not under your control. Also, they typically charge every time you request a new certificate (even if client-only).

The solution to that is to run your own CA but then it won't be 3rd party anymore. It's sort of the catch-22 with SSL/TLS: Either you use a 3rd party or you get to automate things. There doesn't appear to be any middle ground.

Why is there no middle ground? Because if the 3rd party CA is doing their job they're investigating every single request for a new certificate. That means you can't just get a new client-side certificate on demand, instantaneously whenever the need arises.

Post reply on HN