Is this technique a secure way to confirm a user's bank account details, without requiring them to provide their credentials?

Question

There are many financial services that can verify a user's bank account by asking for their username and password, and signing in on their behalf. Some examples are Coinbase and TransferWise.

I've come up with a way for a user to verify their bank account details without ever providing their username and password to a third party. I would like to know if there are any security flaws with the following protocol:

• The third party service starts a proxy server that records all traffic.
• The user establishes a TLS connection through the proxy, and verifies the bank's SSL certificate.
• The user signs in using their username and password, and saves their session cookie.
• The user starts a new TLS connection through the proxy, which uses a different master secret.
• The user uses their current session cookie to fetch their account details through the proxy.
• The user signs out and invalidates the session cookie.
• The user sends the final TLS connection's master secret to the third party service.
• The third party service is now able to decrypt the HTML and verify the user's details, such as their full name, phone number, and account balances.

---

Notes:

• If a bank allows a session cookie to be used from multiple IP addresses, the user could just sign in and out on their own machine.
• The user would be viewing the proxied pages on their own machine, so this would also work with two-factor authentication.
• Some online banking websites may not properly invalidate session cookies when a user signs out. However, most (if not all) banks expire a session after 10-15 minutes of inactivity, so the user can just wait for the session to expire before revealing the private key.
• The page HTML could leak more data than necessary. There would be various ways to solve this for different banks. Many banks provide an API for their mobile apps, so you could just proxy some specific API requests to only reveal the necessary information.
• Instead of sending the private key and allowing a third-party to decrypt all of the HTML and cookies, it might be possible to create an encrypted boolean circuit that provides a zero-knowledge proof for the recorded TLS session. The third party could run a computation that verifies the TLS handshake and certificate, decrypts the URL and HTML, then checks for the presence of certain strings to verify the user's account details. The result of the circuit is either true or false, and the third party wouldn't be able to discover any other information about the encrypted session. Alternatively, the circuit outputs could even be the strings of your full name, phone number, and checking account balance. I'm going to try to investigate this approach with the libsnark library, because it's such a fascinating idea!

---

One way to implement this might be to create a WebKit-based browser application that users can download and install. The app could set up a protocol handler in their browser, so that the app opens whenever the user clicks on a URL like <verification scheme>://domain/path. The app would work with any website, but it could also use preconfigured recipes for different banks.

This could also be implemented directly in Firefox and Chrome, but that's not very likely. There's also much better ways to do this. Some modern banks can provide an OAuth token with limited read-only permissions. A bank could even use public key cryptography to just sign your account details using their private key (maybe the private key for their current SSL certificate.)

I think the technique described above might be useful, since it can work for any website (not just banking.) But please let me know if you can spot any security issues here. I'm sure I've misunderstood something about TLS, or maybe there's an even easier way to do this.

Answer 1

I think that the mechanism could in theory work, provided that the user can trust it's bank that their site is setup in a way so that no sensitive information are transferred within the "proof" session. That means at least that only the information relevant to the proof are included in the proof session, that the HTTP session id can not be used by the third party and that no TLS session reuse is done, i.e. that the same key is not used to protect previous or following TLS sessions.

This means that not only the user needs special software to create the proof session but also that the bank needs to be setup in a way to securely support this proof. In my opinion this makes this concept too complex and too unreliable in practice.

Answer 2

I see a potential vulnerability, although I'm not sure myself whether it can really be executed. The risk is not on the client side, but on the third-party side. In fact, I had first added a comment, which I deleted afterwards, because I realized that I was wrong, and this got me thinking about this vulnerability. The comment I deleted, was, that you didn't need the third party proxy, but that you could, as a user, register the TCP flux yourself, and then send this record of TCP flux as a zipped file, together with the key establishment handshake, to the third party, as a "proof of past session". But then I realized that this is no proof, because the actual content of the session is encrypted in TLS with a symmetric key, so, you, as a user, could modify it as you'd like, too, because you too, have the symmetric key. You can also calculate all kinds of MAC with that key. If your bank sent you that you are long overdue on a negative balance during the session, you can modify this into an account display with 5 million dollars on your account. The certificate is from the bank, the negotiated symmetric key is true, but the content can be determined by not only the bank, but by you too. So I erased my erroneous suggestion.

However, I think one can do the same thing through the proxy. If you, as a user, set up a fake web socket on one of your machines, and instead of contacting the bank through the third party proxy, you contact your machine, which acts as a second proxy, and will contact the bank, you can do a MITM attack on your own TLS session with that proxy, because you know the symmetric key, and modify at your will, the content, just like in my erased comment. If the bank tells you you're overdue, you can modify this on the fly in your proxy, and show an account balance of 5 million dollars, which is the TCP stream that the third party will decrypt.

Of course, if the third party is attentive, it can see that the IP address you went to, doesn't correspond to a bank IP address. But it will have a correct certificate, and a correct key negotiation.