Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
1–10 of 186 posts
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#2This 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.
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#3It'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.
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#4I thought client certificates were being phased out, didn't Chrome just remove the html tag?
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#5This 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.
I gathered the target group are developers. Devs should be capable of dealing with this if they want higher security.
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#6This 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.
I gathered the target group are developers. Devs should be capable of dealing with this if they want higher security.
Even dev's can't cope. Most apps leak credentials severely. You need integratity verification, obfuscation and whitebox crypto to do this sort of thing securely.
All of that is available in the banking world and is often deployed by people like Irdeto (who I work for) and Arxan etc.
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#7I thought client certificates were being phased out, didn't Chrome just remove the html tag?
A PKCS#10 request is built using PKI.js, all crypto is done by native WebCrypto APIs.
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#8This 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.
If you can cope with OAuth you can definitely manage TAuth. The cert and private key are just opaque things you pass to any HTTP client.
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#9Earlier quoted context omitted.
I gathered the target group are developers. Devs should be capable of dealing with this if they want higher security.
Even dev's can't cope. Most apps leak credentials severely. You need integratity verification, obfuscation and whitebox crypto to do this sort of thing securely. All of that is available in the banking world and is often deployed by people like Irdeto (who I work for) and Arxan etc.
Is that why irdeto.com does not use SSL on their site? Because you're not willing to manage SSL certificates?
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#10As much as I love Stevie, teller.io and this demo: Why not both?
OAuth 2 is not "bad" in general, you just need to consider the implications of using it. If you have an API that allows clients to move customers' money or take out loans, you should take additional steps to defend against MITM attacks. For example using client side certificates :)
That said, TAuth looks really good and tidy. Of course the developer may still lose the private key, so in the end you'll always need to additionally monitor API requests for suspicious behaviour.