8

In Norway we have something called BankID which is a login solution for banks and other stuff. It consists (from a users point of view) of a Java applet where you enter your SSN (person number), a one time generated numeric code by a dongle and a personal password.

What I'm curious about is, what is the reason for using a Java applet for this over simple HTML forms over SSL? What does a Java applet add to those three text fields? Or doesn't it really add that much, but rather depend on someone making a technology choice a while ago that probably should've been remade now?

For example Google offers two-phase sign-in without any Java involved. Is that less secure somehow than this BankID which uses the Java applet?

Improve this question
1

4 Answers 4

Reset to default
4

The main situations where I have encountered Java applets for authentication purposes are signatures. Consider that the server or the client could be an attacker; typically, an online banking/stock exchange site. The user can send buy and sell orders, and may later on try to default on his orders by claiming that he never sent them in the first place, and that the bank is trying to frame him. At that point, the customer and the bank go to see a judge.

In a typical password-over-SSL authentication, on the technical side of things, the bank loses. Indeed, the bank can be reasonably certain that the customer indeed came and sent the orders; but it cannot prove it. For a proof, a digital signature is needed: the customer signs the order, with a private key that the bank knows not. A client certificate for SSL is not sufficient, because the client signature is then upon the SSL session elements, not the application data.

So some custom code must be executed on the client machine. That code must be provably honest since the customer will try to claim that any code sent by the bank could be making signatures without him knowing it. Javascript is not sufficient for that. But a signed Java applet can do the trick: the .jar files will be cached on the client's machine, are signed (so the bank cannot repudiate them), and could be reverse-engineered (this is not that hard for Java bytecode).

Note that, similarly, the applet signature protects the customer, since any felony from the bank itself could be uncovered that way; the signature makes frauds more risky, thus (presumably) less probable.

I am not claiming that this is what your specific example of Java applet does, but at least it is a scenario where Java applets have benefits for security.

Improve this answer
5
  • However, in this scenario a signature doesn't actually provide the customer any greater security against the most common kind of attack -- namely, malware on the client machine. Consequently, the Java applet may be providing a false sense of security, and it may be transferring the risk from the bank to the customer (nice trick, for the bank, but not very friendly to customers), but it's not adding additional security or protecting the customer against the most common kind of online fraud.
    – D.W.
    Sep 5, 2012 at 16:22
  • @D.W.: oh yes. The type of signature applet I described adds protection only in the case of a dispute between the customer and the bank (i.e. the customer claiming that the bank is framing him). It is not about third parties like malware running on the customer's machine (then the malware is framing the customer, not the bank).
    – Thomas Pornin
    Sep 5, 2012 at 17:42
  • There are digital signatures in SSL, just use mutual auth and all the guarantees that can be made are there.
    – ewanm89
    Sep 5, 2012 at 18:03
  • 1
    @ewanm89: nope. The signatures of SSL are on hashes obtained in the initial handshake. This is good authentication (both client and server are sure to talk to each other) but this is no good proof for a third party (a judge). The server could show evidence that the client really talked to it, but no verifiable proof about the contents of the conversation.
    – Thomas Pornin
    Sep 5, 2012 at 21:46
  • @ThomasPornin in mutual auth that includes the client cert, the whole thing is then used to setup the MAC. But yeah, judges are idiots. And the whole chain can be checked with the right cipher suites selected. It's a bit more problematic, but java is irrelevant. One could also add javascript digital signatures (yuk!) as another solution.
    – ewanm89
    Sep 5, 2012 at 22:14
3

No. A Java applet is not appreciably more secure than two-factor authentication without Java.

There are two primary threats to online banking: (a) client-side malware, and (b) guessing or disclosure of the victim's credentials. The Java applet does not add any security against client-side malware; since the applet runs on the client, it offers no security against client-side malware.

As far as credential guessing or disclosure, the Java applet offers no greater security than, say, Google's two-factor authentication. The primary defense against credential guessing or disclosure in either case is the physical token, which generates or transmits a random one-time code that is algorithmically chosen (so not susceptible to guessing) and is transaction-specific (so not susceptible to disclosure/phishing). A Java applet doesn't offer any stronger security.

In addition, using a Java applet comes with some costs and risks of its own. The primary risk is that it requires all users of online banking to have Java enabled and installed. As we have seen recently, Java has had a number of zero-day security vulnerabilities, some of which have been widely exploited well before any patch or defense was available. Thus, by forcing online banking users to run Java, the BankID system is putting its users at greater risk and increasing the likelihood of compromise by client-side malware, which might in turn increase the risk of online banking fraud.

Also, BankID requires the user to use a browser that is compatible with BankID, and makes it harder to do your online banking from Linux. This is a cost of its own, and it is also a security risk, because it means you can't easily do your online banking by booting to a Linux LiveCD; pushing users over to Windows for their online banking may be increasing their risk.

Improve this answer
1
  • It adds some security against certain classes of client side malware, such as javascript based browser attacks. But it's minor.
    – ewanm89
    Sep 5, 2012 at 17:59
0

Two factor authentication as Google does is fairly secure, depends on the PRNGs and seed storage though. The applet is probably just a form and so is working the same way.

As for Java applet login it's a lot more murky in terms of security benefits. Arguments for go along the lines of its ubiquitous known technology, it doesn't matter what browser the user has the applet will run the same with the same level as SSL anyway. Of course this same argument against as is its ubiquitous known technology and a flaw in it will affect everyone using it exactly the same. There have been attacks on Java, it is not bulletproof and attacks have happened against it in the past. Finally unless one remains in the applet, one has to move back to cookies and html for the rest of the banking site anyway, and this could easily be where flaws crop up too.

To conclude, I wouldn't say one way is more or less secure, it's just trading some risks for others.

Improve this answer
3
  • 1
    The benefits seem very dubious to me. Like you said, the rest of the site will be in HTML anyway, unless they built the whole site in a java applet. There might also be usability concerns - not everyone has a java plugin in their browser, slow loading times etc.
    – user10211
    Sep 5, 2012 at 12:14
  • 1
    And the browsers accessibility mechanisms for blind users and such are impaired, I said it was murky at best. Personally I don't like it but I'm not a bank manager...
    – ewanm89
    Sep 5, 2012 at 12:40
  • Yeah, the rest of the site is a regular website. Only the login form appears (eventually...) as a Java applet.
    – Svish
    Sep 5, 2012 at 13:13
0

From what you described, I don't see why the applet will provide more security over a regular HTML form. The multi-factory authentication maybe implemented on both the form and the applet. The encryption process is handled by the web browser and the web server for the information on transit via SSL/TLS. This process is independent from the underling technology (applet, or HTML form).

The bank maybe using "Oracle application forms" for their applications, clients generally access these applications via a java applet. This may be the reason why they use the applet instead of a HTML form.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .