Security of Java takes a dangerous turn for the worse, experts say (ars technica)
Security of Java takes a dangerous turn for the worse, experts say (ars technica)
Posted Sep 13, 2013 6:24 UTC (Fri) by eru (subscriber, #2753)In reply to: Security of Java takes a dangerous turn for the worse, experts say (ars technica) by ibukanov
Parent article: Security of Java takes a dangerous turn for the worse, experts say (ars technica)
BankId implementation uses that to check for common malware infections and to fingerprint the computer. Also, for malware it is harder to subvert their code. Banks do not want to give up on that yet.
Sounds surprisingly complex, is that really needed?
The Finnish bank I use (Nordea) has used for decades an authentication that can be implemented with a bare HTML form (or with a TTY for that matter, it actually started that way): For login, a userid, and a single-use 4-digit code stored offline (you pick the next one from a piece of paper the bank sends you now and then). Transactions also require a final confirmation code, which is not single-use, but chosen from a set of 18 (the bank sends you a single letter as a challenge, you respond with the corresponding 4-digit code from the aforementioned piece of paper). Pretty low-tech, no applets needed. Most other Finnish banks also use something similar.
I have not yet heard of any attack against this that did not involve social engineering. A few years ago, a phishing mail managed to persuade some people to send their id, the next 10 or so login codes and the confirmation codes (this has always surprised me, because it is a lot of work to enter that much data, one would have expected warning bells to start ringing in the mind of the "mark" around entering the 5. code or so).
Posted Sep 13, 2013 6:50 UTC (Fri)
by ibukanov (subscriber, #3942)
[Link]
It is useless... Successful attacks against Norwegian banks often involved malware that just replaced the HTML on the login page with own form that sends the login credentials to a remote server. There an operator manually enter the login information into own browser window and do the payment. Then, to confirm a payment, they tricked the user to enter an extra credentials claiming a security check.
Security of Java takes a dangerous turn for the worse, experts say (ars technica)