Return to Question

There are many web-based services that ask for online banking credentials in order to verify a user's bank account. For example, Coinbase and TransferWise ask the user to provide their banking username and password in plaintext.

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.

• 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. I'm going to try to investigate this approach with the libsnark library, because it's such a fascinating idea!

• 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!

• 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. A verifier could run the 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 verifier wouldn't be able to discover anything about the encrypted data. I'm going to try to investigate this approach with the libsnark library. (It's such a fascinating idea!)

• 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. I'm going to try to investigate this approach with the libsnark library, because it's such a fascinating idea!