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

171–180 of 186 posts

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

#171

Post by icebraining »

_lex wrote: post #22
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…

OAuth is, like much of authentication and authorization that has been well marketed, very technically flawed. It makes a big show of not trusting the recipient application with credentials, but anyone who's actually interested in stealing creds still can. Plus it's way more complicated and has way more failure scenarios than simple password auth. The only saving grace that I saw was that a service no longer has to st…

It makes a big show of not trusting the recipient application with credentials, but anyone who's actually interested in stealing creds still can.

How so, if you're in a browser and you check the URL? It's only flawed here because the app controls the browser itself, but that wasn't the original use case of OAuth.

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

#172

Post by icebraining »

wslh wrote: post #41
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...

"The URL does not match any resource in our repository."

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

#173

Post by obeattie »

sandGorgon wrote: post #164
obeattie wrote: post #121

Earlier quoted context omitted.

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…

As I mentioned earlier..this is predicated on the user having installed a Mondo app. That is not workable. You must have a flow where this works without your app being installed.

Why? In order to have a Mondo account, the user must have our app installed.

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

#174

Post by obeattie »

e12e wrote: post #152
obeattie wrote: post #121

Earlier quoted context omitted.

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

On Mondo, there simply are no passwords at all. Instead, when the user wishes to log into our first-party apps, we send a login link to their registered email.

We'll almost certainly add additional required factors to this process (eg. biometrics), as we see the user logging into the Mondo app on a new device as one of the most critical from a security perspective.

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

#175

Post by sandGorgon »

obeattie wrote: post #173
sandGorgon wrote: post #164

Earlier quoted context omitted.

As I mentioned earlier..this is predicated on the user having installed a Mondo app. That is not workable. You must have a flow where this works without your app being installed.

Why? In order to have a Mondo account, the user must have our app installed.

because people will install your app and then uninstall it. However they may still retain the OTHER developer's app that includes your SDK. This is just how customers behave.

If your flow is blocking on Mondo app being installed - that's fine. This means that the surface area of attack is restricted around your app. That's totally OK.

However - that is a very different positioning than oauth. I would say Oauth will degrade gracefully to your protocol if the endpoint is restricted to another app that must mandatorily be installed on the host device.

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

#176

Post by sjtgraham »

blazespin wrote: post #135
andrewstuart2 wrote: post #109

Earlier quoted context omitted.

My DH comment was a bit aside the point I probably should have made. (Also, apologies for my sarcasm re: bash pipes -- that was unnecessary and probably unproductive). > Public key cryptography can be used with JWT tokens but they don't solve the problem of how the client will generate key pairs, demonstrate proof of possession of the private key, and enrol the public key with the API. JWT is not in any way attemptin…

the problem with this is you're rewriting client ssl, which isn't a very good idea considering how battle tested and hardened it is. how do you know you've dealt with all the edge cases that tls spec writers have been wringing their hands over for like forever. why do a one off impl of client auth inside the oauth protocol? why not use extremely well baked pre-existing infrastructure like webcrypto? it's not like you…

I don't think you read the piece?

- I am not reinventing TLS - This has nothing to do with OAuth - It uses WebCrypto for key gen and CSR signing

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

#177

Post by blazespin »

sjtgraham wrote: post #176
blazespin wrote: post #135

Earlier quoted context omitted.

the problem with this is you're rewriting client ssl, which isn't a very good idea considering how battle tested and hardened it is. how do you know you've dealt with all the edge cases that tls spec writers have been wringing their hands over for like forever. why do a one off impl of client auth inside the oauth protocol? why not use extremely well baked pre-existing infrastructure like webcrypto? it's not like you…

I don't think you read the piece? - I am not reinventing TLS - This has nothing to do with OAuth - It uses WebCrypto for key gen and CSR signing

I was replying to stuart, not to you. He was trying to re-invent tls.

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

#178

Post by e12e »

obeattie wrote: post #174
e12e wrote: post #152

Earlier quoted context omitted.

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

On Mondo, there simply are no passwords at all. Instead, when the user wishes to log into our first-party apps, we send a login link to their registered email. We'll almost certainly add additional required factors to this process (eg. biometrics), as we see the user logging into the Mondo app on a new device as one of the most critical from a security perspective.

I hope that's not biometrics in a potentially attacker-controlled web-view (if such a thing is possible) - biometrics are difficult to revoke...

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

#179

Post by hueving »

sandGorgon wrote: post #169
hueving wrote: post #168

Earlier quoted context omitted.

The customer doesn't need to know the number, that's the point. The only sensitive info is what is being sent, so there is absolutely nothing to gain by spoofing a number and sending junk to the user. It's like me telling you I'm going to email you the passcode to a gate. If Bob overhears this and knows your email and my email, he still isn't in a position to do anything if he can spoof emails. Best case is he sends…

The problem we are attempting to solve is that a third party app is demanding access to your bank account, but you only want to enter your password on the bank page. So the trust that needs to be establishmed, is that a page (being shown by the app through webview) is a genuine bank page and you can go ahead and put in your password there. Bob is impersonating you in the first place and asking for the password. How d…

Bob sends me a code, I type it in to his phishing site. So what? It doesn't actually result in him gaining anything useful because I still haven't revealed any banking login credentials.

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

#180

Post by uncleyo »

bobbyrullo wrote: post #149
uncleyo wrote: post #128

Earlier quoted context omitted.

I completely agree with everything you said and know a bit about OIDC too, but since I'm far from mobile/3rd party apps development, there is one thing I don't understand: client credentials (confidential client) in case of mobile app installed from the marketplace. How is it done? You'd need dynamic client registration, right? I know there's a spec for that and I think I understand the mechanics. That would let you…

I had the same questions, and it's very hard to find the answer - took me a very long time to piece this together but this is how Google does it: 1) You create a "normal" client in Google Developer console (i.e. a web client) 2) You create a native/Android client in the same project . This client is shared across all phones. 3) You add a scope of audience:server:client_id:$NORMAL_CLIENT_ID to auth requests from the m…

I understand that. Problem is that I can "steal" other dev's app client_id and use in my app. So it seems impossible to use such client_id for auditing/evidence. With a web client I cannot do that since I don't own the domain, so I can be proven to be a party in some transaction
Post reply on HN