Quote from: mbelshe on November 07, 2013, 08:26:41 PM

Quote from: waxwing on November 07, 2013, 08:12:47 PM

Quote from: dserrano5 on November 07, 2013, 08:06:58 PM

On a compromised client's computer, the attacker only has to wait for the user to start any transaction. The attack consists in replacing the transaction (generated client-side) into one that sends all funds to the attacker. User doesn't know this, she enters 2FA and encryption key believing everything's ok.

Right, then I'll create the transaction server-side so the user validates it before entering the 2FA and/or her encryption key!

No, because then the attacker will target the server and present a bogus transaction to the user, who will happily agree with it without knowing that it's fake and provide the key.

Only the scenario where both the server and the user are compromised does the attack succeed. This is why mbelshe is proposing the P2SH approach, because two signatures are needed, and they must of course be signing the exact same transaction.

dserrano is right - there are some types of attacks you can't catch. He suggests a real-time attack, where you wait for the user to transact, and then change the contents of the transaction (depending on the API this could be a client-side or server-side attack). For example, you may be able to change the destination address without the user noticing. Of course, all wallets, even local ones, are susceptible to this attack today. But with the client/server hybrid, the server can act as your co-signer and make sure it at least fits the right parameters. In the future, I believe you could use this same mechanism to send to a human co-signer (like a business partner) for a human verification.

But, I think the P2SH address, used either web-based or locally is fundamentally stronger than a single-key address.

Mike

But if the malware changes the payee address under the hood, the partially signed transaction can be pinged off the server and feedback the contents via another route - an email address, or other, so that the user can verify what it is they're sending over the wire, no? If the malware allows this step, and only changes the tx contents on the "real" send, then the test and the real won't match, and the server will reject. This kind of confirmation mechanism is used a lot today, e.g. my online brokerage sends me an email with a pin number to confirm a withdrawal.

The attacker can compromise the way the server's response appears, in principle, but it gets incredibly difficult to compromise if there is this kind of alternative messaging route (email, SMS).