Wednesday, May 30, 2007

VirtualATM vs. GreenBorder

We're pretty familiar with GreenBorder, the virtualization software that Google acquired this week.

As we've talked about before, GreenBorder attempts to do what our TSX-based VirtualATM succeeds in doing: create a secure environment for web browsing sessions, including sessions that require transmission of personal data by consumers.

But pictures speak louder than words - let's "go to the tape". Here's a screenshot of what a keylogger sees when it encounters Google GreenBorder:

Result: Unfortunately, GreenBorder presents hackers with a "green light". The keylogger we used not only captured clean images of the session (and the data entered into the fields) but it also captured the text that was entered too, and was able to route that text back to us in an email.

Here's a screenshot of what that same keylogger sees when it encounters Authentium VirtualATM:

Result: The keylogger was unable to capture any text, or images, from the Authentium VirtualATM session. Yes, our screen shot is less colorful, but that's the idea - you want hackers to capture *zero* data from your PC.

There are many technical differences between the two approaches. Authentium VirtualATM secures each transaction session using a combination of client and downstream technology, and uses much deeper, patent-pending system-level technologies to secure the virtual session.

GreenBorder presents pretty-much just a virtualized environment, and lacks the deeper security that our TSX library provides. The result is a less than totally secure environment that is relatively easy for hackers to capture data from.

Bottom line: Authentium's sessions are totally invisible to screen-scrapers. Personal data entered into fields inside Google's GreenBorder session screens can be captured using keylogger technology.

I know which technology I'll be using to file my taxes through.

1 comment:

kurt wismer said...

if i'm not mistaken, what greenborder (and other sandbox products like it) is actually designed to do is protect the integrity of the host system (by containing the results of a potentially unsafe activity inside a virtual environment)...

that means it is maintaining the security of an existing environment not creating a secure environment as your virtualatm is designed to do...

typically sandbox technology operates under the assumption that the host environment is clean (due in part, i suppose, to the long-standing philosophy that you can't trust a compromised environment) and so doesn't aim to protect your session from the host environment... that makes them a unidirectional barrier rather than a bidirectional barrier...