<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Vincent Gable's Blog &#187; Security</title>
	<atom:link href="http://vgable.com/blog/category/security/feed/" rel="self" type="application/rss+xml" />
	<link>http://vgable.com/blog</link>
	<description>my weblog.</description>
	<lastBuildDate>Tue, 29 Nov 2011 22:20:23 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>Sneaking Malware Into the  App Store</title>
		<link>http://vgable.com/blog/2010/07/21/sneaking-malware-into-the-app-store/</link>
		<comments>http://vgable.com/blog/2010/07/21/sneaking-malware-into-the-app-store/#comments</comments>
		<pubDate>Wed, 21 Jul 2010 08:38:45 +0000</pubDate>
		<dc:creator>Vincent Gable</dc:creator>
				<category><![CDATA[Announcement]]></category>
		<category><![CDATA[iPhone]]></category>
		<category><![CDATA[Programming]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[App Store]]></category>
		<category><![CDATA[Apple]]></category>
		<category><![CDATA[iTunes]]></category>
		<category><![CDATA[Malware]]></category>
		<category><![CDATA[Review Process]]></category>

		<guid isPermaLink="false">http://vgable.com/blog/?p=664</guid>
		<description><![CDATA[It&#8217;s happened. An app that grossly violated Apple&#8217;s terms of service (by enabling free tethering) made it through Apple&#8217;s review process, onto the App Store, and into the #2 most-popular spot before being taken down. Although this app wasn&#8217;t malicious to users, it&#8217;s absolutely malicious to Apple&#8217;s agreements with AT&#038;T and other phone-companies. It is [...]]]></description>
			<content:encoded><![CDATA[<p>It&#8217;s happened. An app that grossly violated Apple&#8217;s terms of service (by <a href="http://appshopper.com/blog/2010/07/20/handy-light-tethering-app-camouflaged-as-flashlight/">enabling <em>free</em> tethering</a>) made it through Apple&#8217;s review process, onto the App Store, and into the #2 most-popular spot before being taken down. Although this app wasn&#8217;t malicious to users, it&#8217;s absolutely malicious to Apple&#8217;s agreements with AT&#038;T and other phone-companies. It is a real demonstration that <strong>Apple can&#8217;t keep malware off the App Store</strong>.</p>
<h3>A Few Sneaky Ideas</h3>
<p>It&#8217;s not hard to come up with ways to fool App-Store reviewers.</p>
<p>You might just <strong>get lucky</strong>. With <a href="http://148apps.biz/app-store-metrics/">over 230,000</a> Apps in the store, reviewers are swamped. They&#8217;re only human and they might not notice some subtle evil &#8212; especially if it&#8217;s not on <a href="http://appreview.tumblr.com/">their naughty-behavior list</a>.</p>
<p><strong>Time-Bombs</strong>, apps that hide their bad-behavior for a few days, are undetectable without periodic audits, since they act normally during the pre-release review period.</p>
<p><strong>Phoning home</strong> to a server that let&#8217;s an app know it&#8217;s passed review and can begin it&#8217;s life of crime, would let an app be even more precise.</p>
<p>With just a few minutes thought, I&#8217;m sure you can think of even more clever tricks, or combination of tricks.</p>
<h3>Not a Fully Open Vulnerability</h3>
<p>That&#8217;s not to say your iPhone is in as much danger as your PC. iOS apps don&#8217;t have the same free-reign that traditional computer programs have. That <a href="http://www.mikeash.com/pyblog/iphone-apps-i-cant-have.html">limits their usefulness</a>, but it also limits the damage they can cause. An iOS App can&#8217;t stop you from killing it, and it can&#8217;t mess with other apps, so it can&#8217;t &#8220;take over&#8221; your phone. But it can do anything it likes with your Contacts, and secretly abuse the phone&#8217;s always-on network connection, and get up to other sorts of minor mischief.</p>
<p>I don&#8217;t have room here to fully analyze the risks of a rogue iPhone&#8217;s program. But generally, the danger isn&#8217;t too great: a little more than a what website can do, a <em>lot</em> less than what a PC program with administrator access can do.</p>
<p>Ultimately, Apple&#8217;s best defense against malware isn&#8217;t control of the App Store review process or iTunes payments (although they help), but control over iOS. A well-designed operating system limits what kinds of malware are possible. The review process can screen for egregious mistakes. But it can&#8217;t catch everything, and it&#8217;s least-able to catch the most clever malware, which ultimately, are the programs we should be most worried about. Apple&#8217;s review process doesn&#8217;t provide real security against modern malware.</p>
]]></content:encoded>
			<wfw:commentRss>http://vgable.com/blog/2010/07/21/sneaking-malware-into-the-app-store/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Experts are Easier to Fool</title>
		<link>http://vgable.com/blog/2010/05/24/experts-are-easier-to-fool/</link>
		<comments>http://vgable.com/blog/2010/05/24/experts-are-easier-to-fool/#comments</comments>
		<pubDate>Mon, 24 May 2010 15:47:24 +0000</pubDate>
		<dc:creator>Vincent Gable</dc:creator>
				<category><![CDATA[Quotes]]></category>
		<category><![CDATA[Research]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[Cons]]></category>
		<category><![CDATA[Experts]]></category>
		<category><![CDATA[Scams]]></category>

		<guid isPermaLink="false">http://vgable.com/blog/?p=605</guid>
		<description><![CDATA[Another counter-intuitive finding is that scam victims often have better than average background knowledge in the area of the scam content. For example, it seems that people with experience of playing legitimate prize draws and lotteries are more likely to fall for a scam in this area than people with less knowledge and experience in [...]]]></description>
			<content:encoded><![CDATA[<blockquote><p>Another counter-intuitive finding is that <strong>scam victims often have better than average background knowledge in the area of the scam content</strong>. For example, it seems that people with experience of playing legitimate prize draws and lotteries are more likely to fall for a scam in this area than people with less knowledge and experience in this field. This also applies to those with some knowledge of investments. Such knowledge can increase rather than decrease the risk of becoming a victim.</p></blockquote>
<p>(<a href="http://www.schneier.com/blog/archives/2009/06/the_psychology_3.html">via Bruce Schneier</a>)</p>
]]></content:encoded>
			<wfw:commentRss>http://vgable.com/blog/2010/05/24/experts-are-easier-to-fool/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Spurious</title>
		<link>http://vgable.com/blog/2009/11/09/spurious/</link>
		<comments>http://vgable.com/blog/2009/11/09/spurious/#comments</comments>
		<pubDate>Mon, 09 Nov 2009 22:09:29 +0000</pubDate>
		<dc:creator>Vincent Gable</dc:creator>
				<category><![CDATA[Announcement]]></category>
		<category><![CDATA[Programming]]></category>
		<category><![CDATA[Quotes]]></category>
		<category><![CDATA[Research]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[Analysis]]></category>
		<category><![CDATA[Batman]]></category>
		<category><![CDATA[Correlation]]></category>
		<category><![CDATA[Data]]></category>
		<category><![CDATA[Drowning]]></category>
		<category><![CDATA[Fallacy]]></category>
		<category><![CDATA[Ice Cream]]></category>
		<category><![CDATA[Lisa Wade]]></category>
		<category><![CDATA[Statistics]]></category>
		<category><![CDATA[Summer]]></category>

		<guid isPermaLink="false">http://vgable.com/blog/?p=490</guid>
		<description><![CDATA[What’s a spurious relationship? Here’s one: People who eat ice cream are more likely to drown. Both incidence of ice cream eating and rates of drowning are related to summertime. The relationship between ice cream and drowning is spurious. That is, there is no relationship. Yet they appear related because they are both related to [...]]]></description>
			<content:encoded><![CDATA[<blockquote><h3>What’s a spurious relationship?</h3>
<p>Here’s one: <strong>People who eat ice cream are more likely to drown</strong>.  Both incidence of ice cream eating and rates of drowning are related to summertime.  The relationship between ice cream and drowning is spurious.  That is, there is no relationship.  Yet they appear related because they are both related to a third variable.
</p></blockquote>
<p>&#8211;<a href="http://contexts.org/socimages/2009/06/06/the-contact-hypothesis-and-spurious-relationships/">Lisa Wade</a></p>
<div style="text-align:center;"><img src="http://vgable.com/blog/wp-content/uploads/2009/11/untitled5sk.jpg" alt="untitled5sk.jpg" border="0" width="400" height="595" /></div>
<p>(Image <a href="http://superdickery.com/index.php?view=article&#038;catid=30%3Aframes-and-panels-index&#038;id=788%3Abatman-hates-ice-cream&#038;option=com_content&#038;Itemid=24">via</a> the amazing <a href="http://superdickery.com/">Superdickery</a>)</p>
]]></content:encoded>
			<wfw:commentRss>http://vgable.com/blog/2009/11/09/spurious/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Ignorance is Moral Strength</title>
		<link>http://vgable.com/blog/2009/10/24/ignorance-is-moral-strength/</link>
		<comments>http://vgable.com/blog/2009/10/24/ignorance-is-moral-strength/#comments</comments>
		<pubDate>Sat, 24 Oct 2009 15:38:37 +0000</pubDate>
		<dc:creator>Vincent Gable</dc:creator>
				<category><![CDATA[Design]]></category>
		<category><![CDATA[Quotes]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[Anti-intellectual]]></category>
		<category><![CDATA[Blackjack]]></category>
		<category><![CDATA[Bruce Schneier]]></category>
		<category><![CDATA[Cheating]]></category>
		<category><![CDATA[Gambling]]></category>
		<category><![CDATA[Games]]></category>

		<guid isPermaLink="false">http://vgable.com/blog/?p=480</guid>
		<description><![CDATA[I have long been impressed with the casino industry&#8217;s ability to, in the case of blackjack, convince the gambling public that using strategy equals cheating. &#8211;Bruce Schneier]]></description>
			<content:encoded><![CDATA[<blockquote><p>I have long been impressed with the casino industry&#8217;s ability to, in the case of blackjack, convince the gambling public that using strategy equals cheating.</p></blockquote>
<p>&#8211;<a href="http://www.schneier.com/blog/archives/2009/10/computer_card_c.html">Bruce Schneier</a></p>
]]></content:encoded>
			<wfw:commentRss>http://vgable.com/blog/2009/10/24/ignorance-is-moral-strength/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Misunderestimating the Cloud</title>
		<link>http://vgable.com/blog/2009/10/14/misunderestimating-the-cloud/</link>
		<comments>http://vgable.com/blog/2009/10/14/misunderestimating-the-cloud/#comments</comments>
		<pubDate>Thu, 15 Oct 2009 01:39:37 +0000</pubDate>
		<dc:creator>Vincent Gable</dc:creator>
				<category><![CDATA[Programming]]></category>
		<category><![CDATA[Quotes]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[Bias]]></category>
		<category><![CDATA[Cloud Computing]]></category>
		<category><![CDATA[Failure]]></category>
		<category><![CDATA[Risk Assessment]]></category>
		<category><![CDATA[Wordpress]]></category>

		<guid isPermaLink="false">http://vgable.com/blog/?p=438</guid>
		<description><![CDATA[Recently, a Microsoft datacenter lost thousands of mobilephone user&#8217;s personal data. A common response to this story is that this kind of danger is inherent in &#8220;cloud&#8221; computing services, where you rely on some service provider to take care of your data. But this misses the point, I think. Preserving data is difficult, and individual [...]]]></description>
			<content:encoded><![CDATA[<p>Recently, <a href="http://arstechnica.com/business/news/2009/10/t-mobile-microsoftdanger-data-loss-is-bad-for-the-cloud.ars">a Microsoft datacenter <em>lost</em> thousands of mobilephone user&#8217;s personal data</a>.</p>
<blockquote><p>A common response to this story is that this kind of danger is inherent in &#8220;cloud&#8221; computing services, where you rely on some service provider to take care of your data. But this misses the point, I think. Preserving data is difficult, and individual users tend to do a mediocre job of it. Admit it: You have lost your own data at some point. I know I have lost some of mine. <strong>A big, professionally run data center is much less likely to lose your data than you are.</strong>
</p></blockquote>
<p>&#8211;<a href="http://www.freedom-to-tinker.com/blog/felten/sidekick-users-data-lost-blame-cloud">Ed Felton</a></p>
<p>It&#8217;s easy to convince yourself of this anecdotally. Look around you, how many people people that you loosely know on Facebook have you seen complain about losing all their contacts when they lost their phone? I&#8217;ve seen at least a dozen <a href="http://vgable.com/blog/2008/09/24/i-lost-my-phone-and-need-ur-numbers/">such announcements</a>. But nobody I actually know has been affected by this recent fiasco, or complained about losing contacts in any other &#8220;cloud&#8221; failure.</p>
<p>But people have a bias to overestimate risks they can&#8217;t control, and underestimate risks they can control. So we <a href="http://en.wikipedia.org/wiki/Not_Invented_Here">reinvent the wheel</a>, and lose our own data ourselves.</p>
<p>Hey, I do it too. Actuarially, I really should be <a href="http://en.wordpress.com/products/">paying wordpress.com</a> to manage this blog.</p>
]]></content:encoded>
			<wfw:commentRss>http://vgable.com/blog/2009/10/14/misunderestimating-the-cloud/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Strange AOL Instant Message Filtering</title>
		<link>http://vgable.com/blog/2009/09/18/strange-aol-instant-message-filtering/</link>
		<comments>http://vgable.com/blog/2009/09/18/strange-aol-instant-message-filtering/#comments</comments>
		<pubDate>Fri, 18 Sep 2009 23:10:57 +0000</pubDate>
		<dc:creator>Vincent Gable</dc:creator>
				<category><![CDATA[Announcement]]></category>
		<category><![CDATA[Bug Bite]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[Adium]]></category>
		<category><![CDATA[AIM]]></category>
		<category><![CDATA[AOL]]></category>
		<category><![CDATA[iChat]]></category>
		<category><![CDATA[JavaScript]]></category>

		<guid isPermaLink="false">http://vgable.com/blog/?p=401</guid>
		<description><![CDATA[You can&#8217;t send a message over AIM that has a JavaScript event handler name, followed by = in it. The message seems to be blocked on the server, not in the client, as this behavior was observed in different AIM clients (iChat, Adium, and meebo.) Examples The following messages can&#8217;t be sent over AIM: onclick= [...]]]></description>
			<content:encoded><![CDATA[<p>You can&#8217;t send a message over AIM that has a <a href="http://www.w3schools.com/TAGS/ref_eventattributes.asp">JavaScript event handler name</a>, followed by <code>=</code> in it. The message seems to be blocked on the server, not in the client, as this behavior was observed in different AIM clients (<a href="http://www.apple.com/macosx/what-is-macosx/ichat.html">iChat</a>, <a href="http://adium.im/">Adium</a>, and <a href="http://www.meebo.com/">meebo</a>.)</p>
<h3>Examples</h3>
<p>The following messages can&#8217;t be sent over AIM:</p>
<blockquote><p><code>onclick=</code></p></blockquote>
<blockquote><p><code>onclick       =</code></p></blockquote>
<blockquote><p><code>Yo dawg, I heard you liked onclick= in your JavaScript…</code></p></blockquote>
<p>Interestingly, using a newline, instead of space, between the handler name and <code>=</code> allows the message to be sent, <em>even though it is still valid HTML/JavaScript</em>. For example, you <em>can</em> send,<br />
<blockquote>
<pre>onclick
=x();
/*this is fine*/</pre>
</blockquote>
<p>I suspect there is an interesting security story behind all of this. <strong>If you know how and why this filtering came to pass, I please leave a comment</strong>.</p>
<p>Thanks to Dustin Silverman for helping me investigate this. In case you were wondering how I stumbled onto this behavior &#8212; I was sending snippets of HTML from <a href="http://twitterglyphs.com/">twitterglyphs.com/</a>  over AIM.</p>
]]></content:encoded>
			<wfw:commentRss>http://vgable.com/blog/2009/09/18/strange-aol-instant-message-filtering/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Fair Coin Tosses</title>
		<link>http://vgable.com/blog/2009/08/28/fair-coin-tosses/</link>
		<comments>http://vgable.com/blog/2009/08/28/fair-coin-tosses/#comments</comments>
		<pubDate>Fri, 28 Aug 2009 13:06:15 +0000</pubDate>
		<dc:creator>Vincent Gable</dc:creator>
				<category><![CDATA[Security]]></category>
		<category><![CDATA[Tips]]></category>
		<category><![CDATA[Coins]]></category>
		<category><![CDATA[Decisions]]></category>
		<category><![CDATA[Gambling]]></category>
		<category><![CDATA[Games]]></category>

		<guid isPermaLink="false">http://vgable.com/blog/?p=383</guid>
		<description><![CDATA[Flipping a coin is, ever so slightly, unfair. As this article (via) points out, there is a bias for a coin to land on the same side it started on. Fortunately, all the biases coins have are systemic biases &#8212; they effect all similar coins the same way. So, with a fair thrower, it&#8217;s possible [...]]]></description>
			<content:encoded><![CDATA[<p>Flipping a coin is, ever so slightly, unfair. As <a href="http://www.codingthewheel.com/archives/the-coin-flip-a-fundamentally-unfair-proposition">this article</a> (<a href="http://www.schneier.com/blog/archives/2009/08/non-randomness.html">via</a>) points out, <strong>there is a bias for a coin to land on the same side it started on</strong>.</p>
<p>Fortunately, all the biases coins have are <em>systemic biases</em> &#8212; they effect all similar coins the same way.</p>
<p>So, with a fair thrower, <strong> it&#8217;s possible to flip twice, and have the bias of the two throws cancel each other out.<br />
</strong> </p>
<h3>Procedure</h3>
<ol>
<li>Put a coin heads-up, and flip it, as you normally would.</li>
<li>Note the result, if certified this will be the decision.</li>
<li>Flip the coin again, <em>exactly</em> as you did in step 1.</li>
<li>If the coin lands on the <em>opposite</em> side as it did in step 2, the result from step 2 is certified. Otherwise, restart from step 1.</li>
</ol>
<p>For maximum fairness and reproducibility, it&#8217;s best to let the coin land on the floor.</p>
<h3>Why This Works</h3>
<p>To simplify discussion, let&#8217;s call the sides of the coin <em>unlikely</em> (U) and <em>likely</em> (L) instead of heads &#038; tails.</p>
<p>There are only 4 possible results to a pair of coin tosses: UU, UL, LU, LL. Obviously LL is most likely, and UU is least likely, so we rethrow if we get either (steps 3-4). That means the only &#8220;certified&#8221; results are UL or LU, and <strong>the odds of getting UL are the same as getting LU</strong>.</p>
<h3>Dexterous Cheating</h3>
<p>Unfortunately, this is not a <a href="http://www.schneier.com/blog/archives/2009/08/self-enforcing.html">self-enforcing protocol</a>, so if the thrower is <a href="http://www.amazon.com/gp/product/630505214X?ie=UTF8&#038;tag=vincgabl-20&#038;linkCode=as2&#038;camp=1789&#038;creative=390957&#038;creativeASIN=630505214X">skillful enough</a>, they can make the second throw go however they like, and keep re-throwing until they get the result they want.</p>
<p>Fortunately, most people aren&#8217;t able to manipulate a coin-toss. If you are worried that someone else is, then only let them flip once, and call the result in the air &#8212; that way they won&#8217;t know which side to pick.  </p>
<p>If <em>you</em> can throw the result, and can&#8217;t find someone else to call the result &#8212; it serves you right for driving away all your friends by cheating at coin tosses, you tosser. But I&#8217;m still impressed.</p>
]]></content:encoded>
			<wfw:commentRss>http://vgable.com/blog/2009/08/28/fair-coin-tosses/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>iPhone Password Correction</title>
		<link>http://vgable.com/blog/2009/08/19/iphone-password-correction/</link>
		<comments>http://vgable.com/blog/2009/08/19/iphone-password-correction/#comments</comments>
		<pubDate>Thu, 20 Aug 2009 01:27:59 +0000</pubDate>
		<dc:creator>Vincent Gable</dc:creator>
				<category><![CDATA[Accessibility]]></category>
		<category><![CDATA[iPhone]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[Usability]]></category>
		<category><![CDATA[Authentication]]></category>
		<category><![CDATA[Auto-Correction]]></category>
		<category><![CDATA[Password]]></category>
		<category><![CDATA[Typing]]></category>
		<category><![CDATA[Typos]]></category>

		<guid isPermaLink="false">http://vgable.com/blog/?p=373</guid>
		<description><![CDATA[Idea: your iPhone knows your passwords, so when you make a small typo, it corrects it for you. There are obviously major security concerns here. But I believe they can be acceptably mitigated by the phone itself. Someone would have to physically use the iPhone to get password correction, and correctly could only happen on [...]]]></description>
			<content:encoded><![CDATA[<p>Idea: your iPhone knows your passwords, so when you make a small typo, <em>it corrects it for you</em>.</p>
<p>There are obviously major security concerns here. But I believe they can be acceptably mitigated by the phone itself. Someone would have to <em>physically</em> use the iPhone to get password correction, and correctly could only happen on the first or second password attempt. Also, correction could be limited to the kinds of typos a person would make.</p>
<p>Passwords are broken by machines, not people. I believe password correction can help people, without substantially helping machines, and compromising security.</p>
<p>It&#8217;s hard to type precisely on an iPhone&#8217;s virtual keyboard. That prevents people from using secure passwords, and that hurts security. Because password correction helps people actually use strong passwords, it should be to be a net security <em>benefit</em>.</p>
]]></content:encoded>
			<wfw:commentRss>http://vgable.com/blog/2009/08/19/iphone-password-correction/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Pass Phrases, Not Passwords</title>
		<link>http://vgable.com/blog/2009/06/01/pass-phrases-not-passwords/</link>
		<comments>http://vgable.com/blog/2009/06/01/pass-phrases-not-passwords/#comments</comments>
		<pubDate>Mon, 01 Jun 2009 14:33:57 +0000</pubDate>
		<dc:creator>Vincent Gable</dc:creator>
				<category><![CDATA[Accessibility]]></category>
		<category><![CDATA[Research]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[Usability]]></category>
		<category><![CDATA[Authentication]]></category>
		<category><![CDATA[English]]></category>
		<category><![CDATA[Pass-Phrases]]></category>
		<category><![CDATA[Password]]></category>
		<category><![CDATA[Randomness]]></category>

		<guid isPermaLink="false">http://vgable.com/blog/2009/06/01/pass-phrases-not-passwords/</guid>
		<description><![CDATA[Thomas Baekdal makes a convincing argument for using pass-phrases not passwords (via). It&#8217;s excellent advice, and I know I&#8217;m not alone in having advocated it for years. My keyboard has 26 letters, 10 numbers, and 12 symbol keys, like ~. All but spacebar make a different symbol when I hold down shift, giving me 93 [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://www.baekdal.com/articles/Usability/password-security-usability/">Thomas Baekdal makes a convincing argument for using pass-<em>phrases</em> not pass<em>words</em></a> (<a href="http://delicious.com/hublicious">via</a>). It&#8217;s excellent advice, and I know I&#8217;m not alone in having advocated it for years. </p>
<p>My keyboard has 26 letters, 10 numbers, and 12 symbol keys, like ~. All but spacebar make a different symbol when I hold down shift, giving me 93 characters to use in my passwords. But <strong> the number of words that can make-up a pass-phrase is <em><a href="http://en.wikipedia.org/wiki/English_language#Number_of_words_in_English">easily</a></em> in the 100,000s</strong>. Estimating exactly how big is a bit tricky, but I will stick with 250,000 here (I think it&#8217;s an <em>undercount</em>, more on this later).</p>
<h3>We Know How To Talk</h3>
<p>The human brain has an <em>amazing</em> aptitude for language. But &#8220;passwords&#8221; aren&#8217;t really words, so they don&#8217;t tap into this ability. In fact, <strong>we often use <em>words</em> to try and remember the nonsense-characters of a password</strong>.</p>
<p>Wouldn&#8217;t it make more sense to just use the words directly, if we can remember them more easily?</p>
<h3>Hard For Computers, Not Hard For Us</h3>
<p><strong>People <em>feel</em> that if security system A is harder for them to use then system B, then A must be harder for an attacker to bypass</strong>. But the facts don&#8217;t always match this intuition.</p>
<p>What authentication code do you think is harder for a bad guy to hack, the 7 character <a href="http://strongpasswordgenerator.com/">strong password</a> &#8220;1Ea.$]/&#8221;, or the mnemonic for the first 3 characters, &#8220;One Elvis Amazon&#8221;? Certainly &#8220;1Ea.$]/&#8221; is harder for a person to remember. It <em>feels</em> like it <em>should</em> be harder to break. But a computer, not a person, is going to be doing the guessing, and all it cares about is how big the search space is. There are 93<sup>7</sup> possible 7 character passwords. Let&#8217;s say there are 250,000 possible English words (more on that figure later). Then there are 250,000<sup>3</sup> 3 word combinations &#8212; meaning an attacker would have to do 260 <em>times</em> more work to guess &#8220;One Elvis Amazon&#8221; than to guess &#8220;1Ea.$]/&#8221;.</p>
<p>With pass phrases, easier for the good guys is also harder for the bad guys.</p>
<h3>Exactly How Much Harder</h3>
<p>The &#8220;250,000 word&#8221; figure is a bunch of hand-waiving, but I believe it&#8217;s an <em>undercount</em>. I picked it, because I wanted a round number to crunch; <a href="http://www.baekdal.com/articles/Usability/password-security-usability/">it&#8217;s what Thomas Baekdal</a> picked; and it&#8217;s about the size of <a href="http://en.wikipedia.org/wiki/Words_(Unix)">the Mac OS X words file</a>,</p>
<pre>
$ wc -l /usr/share/dict/words
  234936</pre>
<p>But liberally descriptive linguists say that <a href="http://www.languagemonitor.com/?p=368">the 1,000,000th word will be added to the English Language on June 10th, 2009</a>. The more conservative <cite>Webster&#8217;s Third New International Dictionary, Unabridged</cite> list 475,000 English words. Obviously <strong>neologisms, slang, and archaic terms are fine for pass phrases</strong>. People <em>like</em> <a href="http://www.google.com/search?rls=en-us&#038;q=word+of+the+day&#038;ie=UTF-8&#038;oe=UTF-8">discovering quirky words</a>. I see far more more people embracing the login, &#8220;kilderkin of locats&#8221;, then rejecting it.</p>
<p><strong>Different conjugations (can) count as different words in pass-phrases.</strong> There&#8217;s only one entry in a dictionary for swim, but swim, swimming, swam, etc. make for distinct pass-phrases (eg. &#8220;Elvis <strong>swims</strong> fast&#8221;, &#8220;Elvis <strong>swam</strong> fast&#8221;, etc. Both phrases don&#8217;t show up in a google search by the way.) So <strong>the real number of words should be a few fold larger than a dictionary indicates</strong>.</p>
<p>But <strong>not all words are equally likely to be chosen</strong> &#8212; just as <a href="http://www.schneier.com/blog/archives/2006/12/realworld_passw.html">some characters are more popular in passwords</a>. My earlier figure of &#8220;250000<sup>3</sup> 3 word combinations&#8221; was based on the naive assumption that each of the 3 words is <a href="http://en.wikipedia.org/wiki/Independent_variable">independent</a>. But <a href="http://scienceblogs.com/cognitivedaily/2007/02/is_17_the_most_random_number.php">people do not pick things at random</a>. And a phrase is <em>by definition</em> not completely random &#8212; it must have <a href="http://en.wikipedia.org/wiki/Subject_Verb_Object">some structure</a>. I&#8217;m unaware of research into exactly how predictable people are when making-up pass-phrases. </p>
<p>But given how <em>terrible</em> we are at picking good passwords, and how good we are at remembering non-nonsense-words, I am optimistic that we can remember pass-phrases that are orders of magnitude harder to guess than the &#8220;good&#8221; passwords we can&#8217;t remember today.</p>
<h3>Fewer Ways To Fail</h3>
<p>We&#8217;ve all locked ourselves out of an account because of typos or <a href="http://imlocation.wordpress.com/2007/07/28/caps-lock/">caps lock</a>. But pass-phrases can be more forgiving.</p>
<p>Pass-phrases are case<em>in</em>sensitive. There&#8217;s no need to lock someone out over &#8220;ELvis&#8230;&#8221;.</p>
<p>Common typos can be auto-corrected, much as google automatically suggests words. Consider the authentication attempt &#8220;Elvis <em>Swimmms</em> fast&#8221;. The system could recognize that &#8220;Swimms&#8221; isn&#8217;t a word, and try the most likely correction, &#8220;Elvis <strong>Swimms</strong> fast&#8221; &#8212; if it matches, then there&#8217;s no reason to ask the user if it&#8217;s what they really meant. (Note that only one pass-phrase is checked per login attempt.) I don&#8217;t have hard data here, but given how successful google is at interpreting typos, I&#8217;d expect such a system to work very well.</p>
<p>Pass-phrases might be more difficult on Phones, and similarly <a href="http://rands.tumblr.com/post/93333051/roughly-30-apology">awkward to write with</a> devices. Writing more letters means more work. <a href="http://en.wikipedia.org/wiki/Predictive_text">Predictive text</a> can only do so much. Repeatedly typing 3 letters <em>and</em> accepting a suggestion is clearly more work then just tapping out 6 characters. Additionally, there are security concerns with a predictive text system remembering your pass-phrase, or even a small part of it. </p>
<p>But for computers, pass phrases look like a clear usability win.</p>
<h3>Easily Secure Conclusion</h3>
<p>(In case you were wondering <a href="http://www.google.com/search?hl=en&#038;q=%22Easily+Secure+Conclusion%22&#038;btnG=Search&#038;aq=f&#038;oq=&#038;aqi=">that was a unique phrase</a> when I wrote this.) Using pass-<em>phrases</em> over passwords (which are really pass-strings-of-nonsense-sybols-that-<a href="http://www.schneier.com/blog/archives/2005/06/write_down_your.html">nobody-can-remember</a>) makes a system significantly harder to crack. Pass-phrases are easier for humans to remember, and a system that uses them can be very forgiving. But as always, the devil is in the details. It&#8217;s terrifying to be an early adopter of a new security practice, even if it seems sound.</p>
]]></content:encoded>
			<wfw:commentRss>http://vgable.com/blog/2009/06/01/pass-phrases-not-passwords/feed/</wfw:commentRss>
		<slash:comments>7</slash:comments>
		</item>
		<item>
		<title>Secret Questions Are a Bad Idea</title>
		<link>http://vgable.com/blog/2009/05/26/secret-questions-are-a-bad-idea/</link>
		<comments>http://vgable.com/blog/2009/05/26/secret-questions-are-a-bad-idea/#comments</comments>
		<pubDate>Tue, 26 May 2009 07:20:58 +0000</pubDate>
		<dc:creator>Vincent Gable</dc:creator>
				<category><![CDATA[Design]]></category>
		<category><![CDATA[Quotes]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[Usability]]></category>
		<category><![CDATA[Google]]></category>
		<category><![CDATA[Password]]></category>
		<category><![CDATA[Privacy]]></category>
		<category><![CDATA[Web]]></category>

		<guid isPermaLink="false">http://vgable.com/blog/2009/05/26/secret-questions-are-a-bad-idea/</guid>
		<description><![CDATA[Secret questions are an easier way for someone to hack your account. I don&#8217;t see that they offer much over asking people to pick an insecurely convenient password. Here&#8217;s some data on how insecure secret questions are, Acquaintance with whom participants reported being unwilling to share their webmail passwords were able to guess 17% of [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://www.schneier.com/essay-081.html">Secret questions are an easier way for someone to hack your account.</a> I don&#8217;t see that they offer much over asking people to pick an insecurely <em>convenient</em> password.</p>
<p>Here&#8217;s some data on how insecure secret questions are,</p>
<blockquote><p> Acquaintance with whom participants reported being unwilling to share their webmail passwords were able to <strong>guess 17% of their answers</strong> (to &#8220;secret&#8221; questions). Participants <strong>forgot 20% of their own answers</strong> within six months. What&#8217;s more, <strong>13% of answers could be guessed within five attempts by guessing the most popular answers</strong> of other participants, though this weakness is partially attributable to the geographic homogeneity of our participant pool.</p></blockquote>
<p>&#8211; <a href="http://research.microsoft.com/apps/pubs/default.aspx?id=79594"><cite><br />
It&#8217;s no secret: Measuring the security and reliability of authentication via &#8216;secret&#8217; questions</cite>, Stuart Schechter, A. J. Bernheim Brush, Serge Egelman, 17 May 2009</a></p>
<p>(Via <a href="http://www.schneier.com/blog/archives/2009/05/secret_question.html">Bruce Schneier</a>)</p>
<p>It&#8217;s important to note that <strong>people often forget answers to their own secret questions</strong>. Anecdotally, I&#8217;ve had to call my bank twice because I forgot <em>exactly</em> how I typed in my answers. </p>
<p>Forgetting the answer to a secret question can be <em>embarrassing</em>, unlike forgetting a password. I once got my mother&#8217;s maiden name wrong repeatedly. It was pretty awkward. (A credit card was also in my mother&#8217;s name, so when they asked &#8220;for my mother&#8217;s maiden name&#8221; they really meant <em>her</em> mother&#8217;s maiden name.)</p>
<p>I don&#8217;t know of any statistics on how often accounts are compromised by secret questions. But there have been high-profile cases, like <a href="http://www.wired.com/threatlevel/2008/09/palin-e-mail-ha/">Sarah Palin&#8217;s email</a>,</p>
<blockquote><p>&#8230;the Palin hack didn’t require any real skill. Instead, the hacker simply reset Palin’s password using her birthdate, ZIP code and information about where she met her spouse — <strong>the security question on her Yahoo account, which was answered (Wasilla High) by a simple Google search</strong>.</p></blockquote>
<p><a href="http://www.schneier.com/essay-081.html">Bruce Schneier says,</a> &#8220;Passwords have reached the end of their useful life. Today, they only work for low-security applications. The secret question is just one manifestation of that fact.&#8221; If you must use password authentication, then don&#8217;t weaken it further with a questionable back door.</p>
]]></content:encoded>
			<wfw:commentRss>http://vgable.com/blog/2009/05/26/secret-questions-are-a-bad-idea/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

