Developers › ODIN blog

Banking, the ActiveX challenge

November 13, 2009 · by Zi Bin, Cheah

I was invited to speak to a group of developers at the China Bank of Communications. It was an opportunity to get to know how the IT side of the banking sector works, and to ask them "Why ActiveX?"

First, some background - most if not all Chinese banks use ActiveX for their customer banking, so without ActiveX you can't do online banking in China. Similar issues are happening in South Korea and perhaps other places too. The ActiveX plugin is used to prevent the stealing of passwords by keylogger trojans.

After presenting, the discussion dived right into questions and answers; it was very stimulating and I learned a lot about the perspective of developers working with banks. During the discussion, the thousand dollar question was "If not ActiveX, then what?" I suggested three possible solutions:

  • First, if your bank insists on using plugins, then use the NPAPI plugin interface. NPAPI is arguably more secure than ActiveX because it is solely an Internet plugin, while ActiveX can also tinker with your operating system (for example components in Office applications). Opera, Safari and Firefox all support the NPAPI plugin.
  • If ActiveX is used only to prevent keyloggers, then another solution might be to only allow users to type their login credentials using a virtual keyboard. This could however be a bane for accessibility.
  • The third option is to drop plugins altogether and use a one-time password generator. This crossed my mind with banks in Norway which I am provided with a calculator (I use Nordea Bank). A one-time password calculator will not have the spillover security concerns of ActiveX.

Options above are used to prevent password-snatching while a user is typing in the login credentials - before he or she clicks on the login button which sends the login credentials through a HTTPS secure channel.

On the HTTPS side of things, using Extended Validation (EV) certificates will give bank users better assurance since EV certificates goes through a much more rigorous process before it is given out. Browsers with EV support display more information for EV certificates than for previous SSL certificates. IE8, Firefox, Safari, Google Chrome and Opera support Extended Validation.

During the discussion, I realized that many developers are sympathetic towards standards, including those implementing non-standard ActiveX. I used the word sympathetic because many developers I know are idealist and being idealists they want the world to be a better place. The world is a better place without non-standard code, but the reality is that developers earn their living through customers, and therefore maintaining the existing systems that they already use.

There is more than one way to solve the ActiveX dilemma in the banking industry. It's a legacy issue, for sure, but maybe the real problem is resistance to change?

Note: The PDF version of the presentation can be downloaded here, entitled Web 2.0 and Web Standards.

Readers' comments 8

Left under the original article, as archived.

  • Daniel James Hendrycks18. November 2009, 13:10

    :up: Hope they start coding their sites differently.
  • ouzoWTF18. November 2009, 17:00

    lets get it started! :D

  • Charles Schloss18. November 2009, 17:10

    :up: You can even use very strong bit on the certificates also


    Some time soon all browsers will support TLS 1.2, Opera 10 already does
  • Martin Rauscher20. November 2009, 10:47

    Actually I can't see how ActiveX could help prevent keyboard sniffers. If I implement it at driver level there is no possibility to prevent it... And, as soon as a malware is installed, you are lost anyway...
  • Anonymous25. November 2009, 07:28

    Anonymous writes:

    South Korea usage share data:http://trend.logger.co.kr/report/trend_report.tsp?currRptType=pie&rptCode=4050&tps=2009%2F10%2F26&tpe=2009%2F11%2F23&rptType=pie&rptStep=week&mainSel=Microsoft+Internet+Explorer&subSel=&bigCat=

    for reference:http://ko.wikipedia.org/wiki/%EB%8C%80%ED%95%9C%EB%AF%BC%EA%B5%AD%EC%9D%98_%EC%9B%B9_%ED%91%9C%EC%A4%80_%EB%AC%B8%EC%A0%9C
  • Anonymous2. December 2009, 20:37

    Anonymous writes:

    To Hades32-

    Good point. I am mystified by the banker's claim that using an ActiveX plugin prevents keyboard logging. I am disappointed that Zi Bin does not explain or challenge this claim.

    But I remember a scheme that would work even against a logger written at the driver level: it is a special keyboard, combined with a secure card reader, doing all the security encryption on its own built-in processor before Windows gets a crack at it.

    We actually implemented such a keyboard at N*Able Systems back in the 80s. But the market simply did not yet understand the need for such a system, so funding dried up, the company was sold to Wave Systems, which just buried it and forgot about it.
  • Anonymous14. January 2010, 12:17

    Yordan Georgiev writes:

    I have used my account for all possible transactions in Finland on a Symbian phone running https capable browser and one-time password generator. I simply works.
    Why would one go out from standards to implement an architecture ???
  • Yordan Georgiev14. January 2010, 12:20

    Originally posted by anonymous:

    Why would one go out from standards to implement an architecture


    And by the way ... how on earth could they cope with all the implementations for ActiveX on all possible comming Web enabled gadgets - TV's , tablets , car platforms , Androids , Palms etc.

About this article

Published inODIN blog
DateNovember 13, 2009
AuthorZi Bin, Cheah
TagsNPAPI, EV, bank, China, activex, accessibility, applications, browser sniffing, CSS, education, HTML5, mobile
OriginalInternet Archive