<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Virtual Keyboards</title>
	<atom:link href="http://luminescente.com/2006/12/16/annoyances/feed/" rel="self" type="application/rss+xml" />
	<link>http://luminescente.com/2006/12/16/annoyances/</link>
	<description>a little string of the web</description>
	<pubDate>Tue, 06 Jan 2009 10:56:49 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5</generator>
		<item>
		<title>By: Luís Bruno</title>
		<link>http://luminescente.com/2006/12/16/annoyances/#comment-31</link>
		<dc:creator>Luís Bruno</dc:creator>
		<pubDate>Tue, 19 Dec 2006 21:13:01 +0000</pubDate>
		<guid isPermaLink="false">http://luminescente.com/afterdark/2006/12/16/annoyances/#comment-31</guid>
		<description>Besides, the "virtual keypad" technique only fools hardware-based keyloggers.

You might remember SubSeven, a backdoor doodah for Windows, and it's associated screenshot grabber. Automate screen capture on each click and you've subverted the keypad.

Better, only capture screenshots of the current canvas, and then only when you've checked the title bar for " Internet &#124; Firefox". Then, do a little image analysis to check for boxes around the pointer and perform OCR.

Presto, you can use the same pipeline you've used before, and save the content of password "clicks" in the keylog, right next to the username.

If you're a CGD (.pt bank) developer, you get bonus points for hashing usernames and passwords using JavaScript *and* submitting them over SSL. Although I can no longer use Safari's Keychain-based auto-completion (thereby increasing the chances that my bank password is spotted by a shoulder surfer), at least you've ensured that a locally-installed IE-proxy (like Norton's) can't see the information.

Trade-offs, I guess. Bad ones, in my not-very-humble opinion.

BTW, IE 6 doesn't honor "display: block" directly on a link. There are documented hack-arounds, but 1) IE 7 probably broke them, and 2) I don't even remember the details because I can get away with not caring for Internet Explorer's users (in the drug-using sense).

BTW, I pay *my* stupidity tax at bet-and-lose.</description>
		<content:encoded><![CDATA[<p>Besides, the &#8220;virtual keypad&#8221; technique only fools hardware-based keyloggers.</p>
<p>You might remember SubSeven, a backdoor doodah for Windows, and it&#8217;s associated screenshot grabber. Automate screen capture on each click and you&#8217;ve subverted the keypad.</p>
<p>Better, only capture screenshots of the current canvas, and then only when you&#8217;ve checked the title bar for &#8221; Internet | Firefox&#8221;. Then, do a little image analysis to check for boxes around the pointer and perform OCR.</p>
<p>Presto, you can use the same pipeline you&#8217;ve used before, and save the content of password &#8220;clicks&#8221; in the keylog, right next to the username.</p>
<p>If you&#8217;re a CGD (.pt bank) developer, you get bonus points for hashing usernames and passwords using JavaScript *and* submitting them over SSL. Although I can no longer use Safari&#8217;s Keychain-based auto-completion (thereby increasing the chances that my bank password is spotted by a shoulder surfer), at least you&#8217;ve ensured that a locally-installed IE-proxy (like Norton&#8217;s) can&#8217;t see the information.</p>
<p>Trade-offs, I guess. Bad ones, in my not-very-humble opinion.</p>
<p>BTW, IE 6 doesn&#8217;t honor &#8220;display: block&#8221; directly on a link. There are documented hack-arounds, but 1) IE 7 probably broke them, and 2) I don&#8217;t even remember the details because I can get away with not caring for Internet Explorer&#8217;s users (in the drug-using sense).</p>
<p>BTW, I pay *my* stupidity tax at bet-and-lose.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
