Must be British... "authorisation" ?
It uses a UK phone number and supports an EU banking initiative, so I would guess so. Why is that relevant?
Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
21–30 of 186 posts
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#22One 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 store users' passwords to other systems, for persistent interaction with their data. I think this is really why people bother using it.
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#23I thought client certificates were being phased out, didn't Chrome just remove the html tag?
You're going to see a lot more of this, especially in the IoT world. PKI is becoming a requirement.
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#24It's kinda crazy that it has taken so long for someone to actually take an initiative and attempt to make the authentication more secure. I wonder if this is a custom built solution or if Teller.io is using something like HashiCorps Vault to do the whole SSL cert dance. Either way, this looks promising.
> It's kinda crazy that it has taken so long for someone to actually take an initiative and attempt to make the authentication more secure. Not when you consider we've all been subjected to decades of "don't write your own security!!!"
Author here. This is not a new invention. This is standard TLS, and some newer things like WebCrypto brought together.
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#25One 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…
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?
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#26One 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…
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).
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#27One 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 authorisation request
5. User returns to MyLittleApp, OAuth flow completes
In this flow, the user is not exposing their login credentials to the app… at worst, the app could extract their email/phone number. It also introduces another factor into the auth flow: the user's registered device.
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#28One 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…
Username/Password is still the biggest security hole. With or without OAuth.
One way to circumvent that would be to enforce password change after any oauth authorization, but that's not very user friendly.
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#29One 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…
PIN Code Auth is a way to deal with this as well. Similar to how a Roku works on Netflix or something else.
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#30Some 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 verify that they were only ever appended to. And the server should send a non-repudiable confirmation of this back to the client.
Why? If someone compromises the bank or the bank-issued credentials (it seems quite likely that, in at least one implementation, the bank will know the client private keys), the client should be able to give strong evidence that they did not initiate a given transaction by showing (a) their audit log that does not contain that transaction and (b) the server's signature on that audit log.
2. 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. Did I read it wrong?
3. An obvious place where an HSM fits in.
How does TAuth stack up here?
Also, there's a very strange statement on the website:
> to unimpeachably attribute a request to a given developer. In cryptography this is known as non-repudiation.
Is that actually correct as written or did you mean "to a given user"?