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

181–186 of 186 posts

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

#181

Post by [deleted] »

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…

[deleted]

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

#182

Post by blazespin »

uncleyo wrote: post #180
bobbyrullo wrote: post #149

Earlier quoted context omitted.

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

They should allow for push notifications. That'd be more secure

At the end of the day though, everyone has to sign their apps with certs that are pretty well validated. So, it really cuts down on funny business like you mention.

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

#183

Post by ForHackernews »

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

https://news.ycombinator.com/item?id=11637700

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

#184

Post by amluto »

pbnjay wrote: post #75
matthewaveryusa wrote: post #47

Earlier quoted context omitted.

1. Is an awesome idea. Will it work for the tail-end of the log where most maliciousness will occur? The scenario I see is the hacker grabbing the log, and appending transactions to its copy of the log. When you go to contest those transactions, the bank will have a longer log than what your client has. Don't get me wrong there's a lot of use-cases for this: You received a confirmation that a transaction was cancelle…

I would expect the local device audit log to store the server's signed acknowledgement too. With 2-party asymmetric signing this should be pretty much airtight.

A rollback attack is always possible: the bad guy backs up his/her device, does a transaction, and restores the device. (A replay protected memory block + secure enclave can make this hard, but never impossible, to do.) This means that you can't make an ironclad assertion that the very last transaction the bank sees was fraudulent, because you can't be trusted to make such an assertion.

But you're still protected against transactions alleged to have occurred before your last real transaction or, equivalently, you're guaranteed to (in theory) notice the fraud the next time you try to do a genuine transaction.

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

#185

Post by amluto »

sjtgraham wrote: post #35
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 provid…

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

So what, exactly, is non-repudiable? If I go to a highly enlightened court wielding a signature, what can I prove to that court? That my app really did connect to your server at the time I allege it did? This seems weak to me.

Post reply on HN