A bit more context for people who don’t live in South Korea (I’m a South Korean):
Everybody knows that the systems are absurd. Most newer systems don’t require the use of such anti-keylogger programs. This is basically a countrywide legacy that we’re figuring our way out for ~30yrs.
This started in the 90s where South Korea got high speed internet everywhere, and people demanded internet banking… when IE didn’t ship 128-bit AES support due to export laws.
The South Korean govt submitted a law to enforce encryption for such services (i.e. an custom algorithm called SEED and 128-bit or higher keys were required), and without IE support, these encryption were developed in ActiveX. (For who don’t know, it was a COM-based solution to load native code from IE.) Laws and protocols are sticky, and even after IE shipped better encryption, these stayed.
When the anti-keylogger idea was first proposed, it was simple: the anti-keylogger could ship with the encryption support. It was when IE didn’t have a yes/no dialog to ask whether to load native code or not; everything felt easy, and at that point everybody got locked into this legacy mess where nobody could use different browsers other than IE.
When IE added confirmation dialogs, banks instructed customers to press yes. When IE deprecated ActiveX, banks didn’t remove their 20-yr old code straight away; people were advised to turn on ActiveX support from advanced settings (they added step-by-step instructions to help people), and when MS finally ripped out ActiveX, banks just copied their ActiveX components into a separate executable that runs a localhost server. (And that explains the hastily coded JSON support, the never-updated libraries, and so on that the article shows.)
Every time MS tried making running untrusted native code harder, the banks and customers got used to it… until it became acceptable to install 2~3 different executables for each bank, each running a server on a different port.
Thanks to smartphones, newer solutions now develop all of the encryption code in JS, and the legacy now runs in JS without native code. Still legacy, but it’s been much better for the last 5yrs.
Comments
A bit more context for people who don’t live in South Korea (I’m a South Korean):
Everybody knows that the systems are absurd. Most newer systems don’t require the use of such anti-keylogger programs. This is basically a countrywide legacy that we’re figuring our way out for ~30yrs.
This started in the 90s where South Korea got high speed internet everywhere, and people demanded internet banking… when IE didn’t ship 128-bit AES support due to export laws.
The South Korean govt submitted a law to enforce encryption for such services (i.e. an custom algorithm called SEED and 128-bit or higher keys were required), and without IE support, these encryption were developed in ActiveX. (For who don’t know, it was a COM-based solution to load native code from IE.) Laws and protocols are sticky, and even after IE shipped better encryption, these stayed.
When the anti-keylogger idea was first proposed, it was simple: the anti-keylogger could ship with the encryption support. It was when IE didn’t have a yes/no dialog to ask whether to load native code or not; everything felt easy, and at that point everybody got locked into this legacy mess where nobody could use different browsers other than IE.
When IE added confirmation dialogs, banks instructed customers to press yes. When IE deprecated ActiveX, banks didn’t remove their 20-yr old code straight away; people were advised to turn on ActiveX support from advanced settings (they added step-by-step instructions to help people), and when MS finally ripped out ActiveX, banks just copied their ActiveX components into a separate executable that runs a localhost server. (And that explains the hastily coded JSON support, the never-updated libraries, and so on that the article shows.)
Every time MS tried making running untrusted native code harder, the banks and customers got used to it… until it became acceptable to install 2~3 different executables for each bank, each running a server on a different port.
Thanks to smartphones, newer solutions now develop all of the encryption code in JS, and the legacy now runs in JS without native code. Still legacy, but it’s been much better for the last 5yrs.
I wonder if forcing people to use Microsoft Windows for banking is why Linux usage is so low in S. Korea compared to just about anywhere else?
https://gs.statcounter.com/os-market-share/all/south-korea
Multiple orders of magnitude less than most places.
(assuming the numbers in the link are valid)