3 ms·

This is unnecessary. Many banks can and will enforce 2-factor authentication with their oauth flow, which sufficiently validates the client and would prevent a

This is unnecessary. Many banks can and will enforce 2-factor authentication with their oauth flow, which sufficiently validates the client and would prevent a MITM attack. Your whole premise is surrounded by the threat a client browser would not properly validate a server certificate... come on... really?

peterwwillis 10y ago
You do know about phishing, right? There are many ways to get a user (not client) to accept an invalid cert, and some cases where a client will accept an invalid cert. They want cryptographic proof of client identity. That means somehow the client has to prove they are the real user and not an attacker who intercepted the connection somehow (which, again, is completely possible). Client certs are a way to verify with each message that the user themselves, using their private key, validate what's going on, and that the message they validated came from the real server and not a fake intermediary. This is different from 2fa because 2fa is authentication of identity that only happens once and does not provide cryptographic proof of identity. TOTP will give you something closer, but it's still a "dumb token" that can be intercepted. tl;dr 2fa: Client request 1: "Gimme $5." Bank reply 1: "Who are you?" <man-in-the-middle starts listening> Client request 2: "StrawberryNewtonManicDresser" Bank reply 2: "Okay, you can now use session ID 1234 to request more money." MITM request 1: "Gimme $100000." Bank reply 1: "Who are you?" MITM request 2: "Session id 1234." Bank reply 2: "Okay, here's your money." client certs: Client request 1: "Gimme $5." Bank reply 1: "Who are you?" <man-in-the-middle starts listening> Client request 2: <'Gimme my money.' ^ PRIVATE_KEY> Bank reply 2: <verifies CR2 against stored client cert> Bank reply 2: "Okay, you can now use session ID 1234, starting at iteration 2, to request more money." MITM request 1: "Gimme $100000." Bank reply 1: "Who are you?" MITM request 2: "Session id 1234, iteration 2." Bank reply 2: <checks MITMR2 against stored client cert, is not valid because iteration 2 wasn't signed with the client private key> Bank reply 2: "You're a faker, get lost." ....at least, I think that's how it works, iirc. The messages are re-signed so a stolen session token doesn't allow replay by an intermediary (the same sort of protection modern TLS has, but for the server's protection, not the client's) It should be noted that carders, whom normally get their Bank credentials from malware on a user's device, can already inject commands into active valid sessions started by the user, so verifying the user's identity is completely pointless in this case.
- pweissbrod 10y ago
  That seems right to me. It's the same approach as SSH key-based auth in a nutshell
abritishguy 10y ago
2-factor authentication does not protect against that. The victim does not know they are being MITMd and enters the 2FA code.
- Maarten88 10y ago
  The 2FA device from my bank (https://nl.wikipedia.org/wiki/Rabo_Scanner https://nl.wikipedia.org/wiki/Rabo_Scanner) shows what permission is asked: account login, signing a transaction for amount x, etc.. You might MITM it, but it would be hard to profit, because the only thing feasible seems to deflect some transaction to another account, and it would only work once and raise suspicion quickly thereafter. The bank could encode the permission (amount, beneficiary, read access, etc with an expiration date) given into an OAuth bearer token, and the app can use the token to do exactly the things that the user consented to.
  - aianus 10y ago
    I'm amazed (in a good way) that European banks have such advanced security and that the general public goes along with it. If they tried this at a Canadian bank, every non-technical person would immediately switch to a competitor and they'd lose more money than they'd save via fraud prevention.

peterwwillis 10y ago

You do know about phishing, right? There are many ways to get a user (not client) to accept an invalid cert, and some cases where a client will accept an invalid cert. They want cryptographic proof of client identity. That means somehow the client has to prove they are the real user and not an attacker who intercepted the connection somehow (which, again, is completely possible). Client certs are a way to verify with each message that the user themselves, using their private key, validate what's going on, and that the message they validated came from the real server and not a fake intermediary. This is different from 2fa because 2fa is authentication of identity that only happens once and does not provide cryptographic proof of identity. TOTP will give you something closer, but it's still a "dumb token" that can be intercepted. tl;dr 2fa: Client request 1: "Gimme $5." Bank reply 1: "Who are you?" <man-in-the-middle starts listening> Client request 2: "StrawberryNewtonManicDresser" Bank reply 2: "Okay, you can now use session ID 1234 to request more money." MITM request 1: "Gimme $100000." Bank reply 1: "Who are you?" MITM request 2: "Session id 1234." Bank reply 2: "Okay, here's your money." client certs: Client request 1: "Gimme $5." Bank reply 1: "Who are you?" <man-in-the-middle starts listening> Client request 2: <'Gimme my money.' ^ PRIVATE_KEY> Bank reply 2: <verifies CR2 against stored client cert> Bank reply 2: "Okay, you can now use session ID 1234, starting at iteration 2, to request more money." MITM request 1: "Gimme $100000." Bank reply 1: "Who are you?" MITM request 2: "Session id 1234, iteration 2." Bank reply 2: <checks MITMR2 against stored client cert, is not valid because iteration 2 wasn't signed with the client private key> Bank reply 2: "You're a faker, get lost." ....at least, I think that's how it works, iirc. The messages are re-signed so a stolen session token doesn't allow replay by an intermediary (the same sort of protection modern TLS has, but for the server's protection, not the client's) It should be noted that carders, whom normally get their Bank credentials from malware on a user's device, can already inject commands into active valid sessions started by the user, so verifying the user's identity is completely pointless in this case.

pweissbrod 10y ago
That seems right to me. It's the same approach as SSH key-based auth in a nutshell

abritishguy 10y ago

2-factor authentication does not protect against that. The victim does not know they are being MITMd and enters the 2FA code.

Maarten88 10y ago
The 2FA device from my bank (https://nl.wikipedia.org/wiki/Rabo_Scanner https://nl.wikipedia.org/wiki/Rabo_Scanner) shows what permission is asked: account login, signing a transaction for amount x, etc.. You might MITM it, but it would be hard to profit, because the only thing feasible seems to deflect some transaction to another account, and it would only work once and raise suspicion quickly thereafter. The bank could encode the permission (amount, beneficiary, read access, etc with an expiration date) given into an OAuth bearer token, and the app can use the token to do exactly the things that the user consented to.
- aianus 10y ago
  I'm amazed (in a good way) that European banks have such advanced security and that the general public goes along with it. If they tried this at a Canadian bank, every non-technical person would immediately switch to a competitor and they'd lose more money than they'd save via fraud prevention.