> The real number of users is likely considerably higher, the software being installed on pretty much any computer in South Korea.<p>This is a bit of an exaggeration. Plenty of young people hate this stuff enough that they do all of their banking through their phone and if they absolutely must do it on a pc, they either use an old disused laptop, do it at work, do it at an internet cafe (not that those don't bring risks) or make sure to remove the spyware the second they've completed the task at hand.
The first part was discussed on HN a few days ago and provides some background/context:<p><a href="https://news.ycombinator.com/item?id=34231364" rel="nofollow">https://news.ycombinator.com/item?id=34231364</a>
I am very grateful for the modern web. It used to be commonplace to install a bunch of executables that interacted with the browser and took instructions from random websites (Flash, Silverlight, Java applets).<p>I have my reservations with the browserfication of software (and the restriction of browser extensions), but at the same time it is absolutely for the best that normal users just run sandboxed phone apps and browsers these days. Hopefully South Korea will retire this tool soon.
A bit more context for people who don’t live in South Korea (I’m a South Korean):<p>Everybody knows that the systems are <i>absurd</i>. 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.<p>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.<p>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.<p>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.<p>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.)<p>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.<p>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.
It is interesting to see a proprietary, very poor and insecure imitation of Nitpicker's xray mode[0].<p>Note this is written by Norman Feske, who later went on to develop Genode[1], and continues to be its main developer today.<p>0. <a href="http://demo.tudos.org/nitpicker_tutorial.html" rel="nofollow">http://demo.tudos.org/nitpicker_tutorial.html</a><p>1. <a href="https://www.genode.org/" rel="nofollow">https://www.genode.org/</a>
From the article:<p>> The current approach is for the websites to use WebSockets API to communicate with the application directly.<p>Is this really current best practice? I know of a handful of applications that implement webapp to native app communication like this, but it doesn't seem especially stable/portable to me, considering that it usually uses some ephemeral port that applications have no way of globally reserving.<p>Also, how does HTTPS work in this scenario? Wouldn't there be a self-signed certificate or mixed content warning in many cases?
It's interesting how long they could get away with such horrible practices despite having a neighbor up north that a) won't hesitate to use cybercrime to fund their country b) probably wouldn't mind causing some random disruption even if it can't profit from it.
Between this and <a href="https://en.wikipedia.org/wiki/Shutdown_law" rel="nofollow">https://en.wikipedia.org/wiki/Shutdown_law</a> South Korea sounds like pretty oppressive country to live in.
Is two-factor security an alien concept to South Korean banking system? At least via SMS? But either way if they're going to make everyone install an application, why not OTP generator?