> Why is this attack not thwarted by the use of external secure keys? Currently the bank uses a password and a hardware token. Changing that is a long process and using JS-based RSA is considered a temporary measure to raise the bar for attackers.
> That's what my bank has issued me. The one-time 6-digit PIN is tied to some transactional data (last 4 digits of tranferee account number) and so can't be captured and reused for a different transfer. That does not work with more sophisticated injects that just wait until the user perform a payment and change the payment details. Typically they also patch HTML that shows transaction list etc. to hide the fraud and change the total balance. > This seems like a better route than trying to do secure transactions on an insecure machine. The important point here is that from banking point of view current implementations of HTTPS are *insecure* as the users can be tricked to install extra root certificates using relatively simple procedure (https://groups.google.com/d/msg/mozilla.dev.security/zPm2M-ieI20/vzhvipASJD0J talks about doing that for legitimate purposes) even if *the machine is secure*. Add to that the need to trust all authorities issueing certificates that must be evaluated against a possibility of loosing a lot of money and the result is that HTTPS is not much better than HTTP. It is sad since SRP and J-PAKE plus passwords and hardware tokens allows for the user to verify SSL certificate in a cryptographically secure way with minimal support for those protocols on the server side and without any hardware upgrade. Given that Firefox already implements J-PAKE for Sync it is even more pity that that is not available for use on web pages. _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
