Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 12, 2013 6:22 UTC (Thu) by smurf (subscriber, #17840)
In reply to: Security of Java takes a dangerous turn for the worse, experts say (ars technica) by bo
Parent article: Security of Java takes a dangerous turn for the worse, experts say (ars technica)

So get the specs and reimplement it in Javascript and HTML5.

Should not take more than two hours. ;-)

(That being said, the way to find a realistic estimate is to multiply the initial estimate by two and go to the next-higher order of magnitude, so it'd be more like a week.)

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 12, 2013 6:57 UTC (Thu) by geuder (subscriber, #62854) [Link]

> So get the specs

Come on this is about security, so of course the specs must be kept secret

(sorry could not resist... comment not based on specific facts in the case mentioned, but on general experience)

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 12, 2013 7:16 UTC (Thu) by bytelicker (guest, #92320) [Link] (3 responses)

I think you are underestimating how critical it is to implement something like this. Massive amounts of testing is going to be needed. Everything sounds easy on paper. Another important note is that Banks are very paranoid about new technologies; which makes sense. A lot is at stake. Also with a with a HTML5 and Javascript implementation you suddenly rely heavily on browser security. There are many different flavours of browsers out there.

The answer is not an easy one.

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 12, 2013 15:08 UTC (Thu) by drag (guest, #31333) [Link] (2 responses)

Nowadays when I see something like this I think of this quote:

"There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."
-- C.A.R Hoare

Therefore if you want to have a secure login or something like that for a bank the goal is to avoid javascript, java, html5, etc etc.. as much as possible. I don't think there is a way to make these sorts of technologies actually secure.

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 17, 2013 19:11 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

hmm, I've been running modified tivos for over a decade.

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 17, 2013 19:12 UTC (Tue) by dlang (guest, #313) [Link]

oops, wrong thread, sorry

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 12, 2013 9:01 UTC (Thu) by ibukanov (subscriber, #3942) [Link] (4 responses)

The main reason BankId cannot be easily replaced by a JavaScript is that, as a signed applet, it can access a lot of stuff, that ordinary JS cannot. 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.

Still, given how bad the situation with Java, I would not be surprised that after few successful fraud attempts against big customers, banks change their mind.

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 12, 2013 16:54 UTC (Thu) by pboddie (guest, #50784) [Link]

The "check for common malware infections and to fingerprint the computer" is one reason why I always run BankID in some kind of sandbox. I presume that as an implementer one can always make an argument for sniffing around on a person's computer for "security" reasons and to "look after them" in this way, but it's obviously intrusive especially when the actual operations being performed are kept secret (reverse engineering notwithstanding).

The dialogue that gets shown when one has to accept the elevated privileges of the signed applet under certain versions of the Java VM says it all when it tells you that the applet needs access to your system including your webcam. Naturally, the webcam thing is an artefact of Java's "cool" multimedia past, but in this situation it just underlines the creepy nature of a banking login mechanism wanting to poke around on a user's computer.

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 12, 2013 22:43 UTC (Thu) by khim (subscriber, #9252) [Link]

Still, given how bad the situation with Java, I would not be surprised that after few successful fraud attempts against big customers, banks change their mind.

A few banks already did that and now instead of Java applet offer… regular .exe binary which must be installed with Admin privileges because it basically stops everything else on a system while it's running (it disables most network interfaces, removes all routes except routes needed to reach the server, freezes “suspicious programs”, etc).

This looks onerous, but I can kind of understand why they are doing this: my sister is accountant and she sometimes enlist my help in fixing the computers of her fellow accountants. Usually they are infected by literally dozens of viruses and trojans which, of course, makes them somewhat slower. AV software is installed and usually even tries to complain but is silenced “because it's popups make work impossible”.

Frankly this picture makes me sad: we are talking about backdoors and weaknesses in cryptographic standards but what does it change if people are this ignorant?

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) [Link] (1 responses)

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).

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 13, 2013 6:50 UTC (Fri) by ibukanov (subscriber, #3942) [Link]

> Sounds surprisingly complex, is that really needed?

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.