Virtual Keyboards Offer Zero Protection
I like Netbanker.com as a web site. It provides some great stats and adds some clear thinking analysis on the online banking industry, and catalogs its analysis by bank brand. It is my first destination when I'm trying to right-size markets for VirtualATM or analyze what folks already have in place.
A few months ago, they ran a piece on TreasuryDirect.orgs new "virtual keyboard". What a waste of time.
I recently downloaded a keylogger to test VirtualATM's abilities to secure transactions against keyloggers. Transaction information and PIN numbers entered via Authentium's VirtualATM proved to be invisible to the keylogger. The TreasuryDirect.org site wasn't nearly so lucky.
Here's the deal. Online criminals expect banks to put in place screen-based logins that rely on mouse-click PIN inputs into a "virtual keyboard" - which is why they include screen-scrapers as part of their arsenal.
The keylogger I installed yesterday includes a screen-shot capability that is more than capable of defeating any and all of the "virtual keyboard" style PIN input mechanisms: it is designed to take a screen-shot every time the mouse is clicked, then wrap this information into an email and send it back to the hacker. Note to TreasuryDirect guys: scrambling is completely useless.
Is your PIN eight characters in length? Eight screen-shots later, the hacker has your PIN. Your social security number is just a single screen shot away.
Our patent-pending VirtualATM technology is the only technology I have seen in market than can defeat these kinds of sophisticated attacks. Email me if you know of anything even close to what we're doing.
2 comments:
Keyloggers that use screenshots are generally written by amateurs, and are not all that worrying to me; it is extremely easy to fool something like that by say, tabbing to the button and pressing the enter/space bar key. Of course most users do not do this, but it is still possible for the user to do something to stop it.
The attacks you really need to worry about are network shims, library injection (e.g. injecting a network shim into a browser's SSL library), form grabbers, and similar attacks which grab the data in transit, rather than trying to obtain it from the user.
You could of course implement some kind of Zero Knowledge Password proof system, where the password is never sent, or even a simple challenge-response system, but if your product (which I know nothing about) ever becomes a mainstream product for banks, it will be very easy to just implement a network shim that works as an active attacker and injects/modifies the html code interpreted by the browser, and have the browser simply extract the password and send it to an attacker.
It is not easy to fool well-written keyloggers - see my more-recent post. Smart keylogger engineers are not amateurs, and treat *any* PC IO request as a cue to take a screen shot.
I'm not going to go into detail here, but it isn't easy to mess with VirtualATM in the manner you suggest: for one thing, we're not reliant on standard browsers, and we have excellent some of the best end point firewall technologies on the market today. We're already in the business of implementing this form of protection.
Thanks for your contribution.
Post a Comment