<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/1.5.1-alpha" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Nonsense passwords</title>
	<link>http://dansdata.blogsome.com/2006/10/22/nonsense-passwords/</link>
	<description>the blog that is not dansdata.com</description>
	<pubDate>Sun, 06 Dec 2009 20:56:00 +0000</pubDate>
	<generator>http://wordpress.org/?v=1.5.1-alpha</generator>

	<item>
		<title>by: matkun</title>
		<link>http://dansdata.blogsome.com/2006/10/22/nonsense-passwords/#comment-180</link>
		<pubDate>Tue, 24 Oct 2006 23:53:06 +0100</pubDate>
		<guid>http://dansdata.blogsome.com/2006/10/22/nonsense-passwords/#comment-180</guid>
					<description>One devil of a method for adding complexity to passwords is using non-standard ASCII characters.. like: ╚ or ± .. According to that program just one of those in a password adds 15-20 bits of complexity. Only problem is not all passwords support those fiddly characters.</description>
		<content:encoded><![CDATA[	<p>One devil of a method for adding complexity to passwords is using non-standard ASCII characters.. like: ╚ or ± .. According to that program just one of those in a password adds 15-20 bits of complexity. Only problem is not all passwords support those fiddly characters.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: awnm</title>
		<link>http://dansdata.blogsome.com/2006/10/22/nonsense-passwords/#comment-177</link>
		<pubDate>Tue, 24 Oct 2006 11:47:33 +0100</pubDate>
		<guid>http://dansdata.blogsome.com/2006/10/22/nonsense-passwords/#comment-177</guid>
					<description>One bugbear I have about passwords is corporate systems that require users to change them every month, resulting in the entirely predictable &quot;petnamex&quot; password scheme, where x is incremented monthly.

Does anyone have a nice reference to information that could assist in arguments with the corporate security drones about the fact that a rarely changed secure password is vastly superior to a frequently changed predictable password? I always use the example of online banking or ATM PIN numbers (which rarely or never change), but that doesn't seem to be enough.</description>
		<content:encoded><![CDATA[	<p>One bugbear I have about passwords is corporate systems that require users to change them every month, resulting in the entirely predictable "petnamex" password scheme, where x is incremented monthly.</p>
	<p>Does anyone have a nice reference to information that could assist in arguments with the corporate security drones about the fact that a rarely changed secure password is vastly superior to a frequently changed predictable password? I always use the example of online banking or ATM PIN numbers (which rarely or never change), but that doesn't seem to be enough.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: peridot</title>
		<link>http://dansdata.blogsome.com/2006/10/22/nonsense-passwords/#comment-174</link>
		<pubDate>Mon, 23 Oct 2006 16:43:37 +0100</pubDate>
		<guid>http://dansdata.blogsome.com/2006/10/22/nonsense-passwords/#comment-174</guid>
					<description>The number of bits you need for a good password depends on how you're going to use it. Most applications - logging into gmail, say - do not allow massive systematic attempts to crack the passwords. So anything with more than, say, ten bits of entropy is probably enough. Seems like not enough? The way your gmail password is most likely to get cracked, by far, is by you using the same password elsewere, with someone who lets it slip. This is much more of a danger if you use a long, difficult-to-remember one. Alternatively, it can leak when somebody gets a peek into your browser's collection of stored passwords. Anyway, what do you need memorable passwords for if you're storing them? Use some gibberish from /dev/random and copy them every time.

For those rare times you actually *do* need a good password, a dictionary can provide you with a reliable amount of entropy. My /usr/share/dict/words has about 100000 entries, so picking five words really at random gives me a guaranteed 83 bits of entropy. And who can't remember a five-word nonsense phrase? If it's hard, generate eight phrases, pick your favourite, and count on 80 bits.</description>
		<content:encoded><![CDATA[	<p>The number of bits you need for a good password depends on how you're going to use it. Most applications - logging into gmail, say - do not allow massive systematic attempts to crack the passwords. So anything with more than, say, ten bits of entropy is probably enough. Seems like not enough? The way your gmail password is most likely to get cracked, by far, is by you using the same password elsewere, with someone who lets it slip. This is much more of a danger if you use a long, difficult-to-remember one. Alternatively, it can leak when somebody gets a peek into your browser's collection of stored passwords. Anyway, what do you need memorable passwords for if you're storing them? Use some gibberish from /dev/random and copy them every time.</p>
	<p>For those rare times you actually *do* need a good password, a dictionary can provide you with a reliable amount of entropy. My /usr/share/dict/words has about 100000 entries, so picking five words really at random gives me a guaranteed 83 bits of entropy. And who can't remember a five-word nonsense phrase? If it's hard, generate eight phrases, pick your favourite, and count on 80 bits.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: pjcamp</title>
		<link>http://dansdata.blogsome.com/2006/10/22/nonsense-passwords/#comment-173</link>
		<pubDate>Mon, 23 Oct 2006 11:17:10 +0100</pubDate>
		<guid>http://dansdata.blogsome.com/2006/10/22/nonsense-passwords/#comment-173</guid>
					<description>I use physics equations. I spent a month of back and forth with the Georgia Tech password guesser before I hit on that idea.

By the way, Steganos Locknote is another option for keeping passwords secure. It creates an AES-encrypted file with a single password to access it. The encryption is part of the document so you only have one file to keep up with. You could just copy and paste your entire list. I used to use keepass but I am lazy and it was too much maintenance.

</description>
		<content:encoded><![CDATA[	<p>I use physics equations. I spent a month of back and forth with the Georgia Tech password guesser before I hit on that idea.</p>
	<p>By the way, Steganos Locknote is another option for keeping passwords secure. It creates an AES-encrypted file with a single password to access it. The encryption is part of the document so you only have one file to keep up with. You could just copy and paste your entire list. I used to use keepass but I am lazy and it was too much maintenance.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: fnaah</title>
		<link>http://dansdata.blogsome.com/2006/10/22/nonsense-passwords/#comment-172</link>
		<pubDate>Mon, 23 Oct 2006 10:34:55 +0100</pubDate>
		<guid>http://dansdata.blogsome.com/2006/10/22/nonsense-passwords/#comment-172</guid>
					<description>I'm a big fan of the long acronym password, which I guess is similar to a passphrase:

pC+A+D2utc!

&quot;press Ctrl + Alt + Del to unlock this computer&quot;

You can use famous quotes, song lyrics, all sorts of stuff.</description>
		<content:encoded><![CDATA[	<p>I'm a big fan of the long acronym password, which I guess is similar to a passphrase:</p>
	<p>pC+A+D2utc!</p>
	<p>"press Ctrl + Alt + Del to unlock this computer"</p>
	<p>You can use famous quotes, song lyrics, all sorts of stuff.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Mark Cocquio</title>
		<link>http://dansdata.blogsome.com/2006/10/22/nonsense-passwords/#comment-170</link>
		<pubDate>Mon, 23 Oct 2006 09:37:34 +0100</pubDate>
		<guid>http://dansdata.blogsome.com/2006/10/22/nonsense-passwords/#comment-170</guid>
					<description>Passphrases of Vogon Poetry can also be somewhat memorable, if you are into that sort of thing. &quot;O freddled gruntbuggly...&quot;

(no I didn't just give away my passwords) :)</description>
		<content:encoded><![CDATA[	<p>Passphrases of Vogon Poetry can also be somewhat memorable, if you are into that sort of thing. "O freddled gruntbuggly..."</p>
	<p>(no I didn't just give away my passwords) :)
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Daniel Rutter</title>
		<link>http://dansdata.blogsome.com/2006/10/22/nonsense-passwords/#comment-168</link>
		<pubDate>Mon, 23 Oct 2006 05:15:20 +0100</pubDate>
		<guid>http://dansdata.blogsome.com/2006/10/22/nonsense-passwords/#comment-168</guid>
					<description>Indeed, for the vast majority of cases, if everyone's playing fair, then forty-something bits of password (&quot;aA224$(*&quot; is 44) are more than adequate. Again, nonsense words work nicely here - &quot;PombleboM&quot; is 46 bits. 

But there are many factors that can reduce the strength of your password. Encryption weaknesses commonly knock off a few bits, and then there's straightforward stuff like being shoulder-surfed; if the attacker only knows how many characters there are in the password then that won't help him much (unless the fact that it's obviously only four characters is what induced him to try cracking it in the first place...), but if he knows there's a double 2 in it, that helps more.

And it's far from impossible that the next crowd of zombified XP boxes will be running a distributed password cracker for someone. Bingo - processing times divided by a thousand or more, and an unfeasible two year crack becomes an easy 20 hour one.

So there's still good reason to add a few more bits, provided it doesn't make your password uselessly immemorable.</description>
		<content:encoded><![CDATA[	<p>Indeed, for the vast majority of cases, if everyone's playing fair, then forty-something bits of password ("aA224$(*" is 44) are more than adequate. Again, nonsense words work nicely here - "PombleboM" is 46 bits. </p>
	<p>But there are many factors that can reduce the strength of your password. Encryption weaknesses commonly knock off a few bits, and then there's straightforward stuff like being shoulder-surfed; if the attacker only knows how many characters there are in the password then that won't help him much (unless the fact that it's obviously only four characters is what induced him to try cracking it in the first place...), but if he knows there's a double 2 in it, that helps more.</p>
	<p>And it's far from impossible that the next crowd of zombified XP boxes will be running a distributed password cracker for someone. Bingo - processing times divided by a thousand or more, and an unfeasible two year crack becomes an easy 20 hour one.</p>
	<p>So there's still good reason to add a few more bits, provided it doesn't make your password uselessly immemorable.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: David</title>
		<link>http://dansdata.blogsome.com/2006/10/22/nonsense-passwords/#comment-167</link>
		<pubDate>Mon, 23 Oct 2006 04:30:22 +0100</pubDate>
		<guid>http://dansdata.blogsome.com/2006/10/22/nonsense-passwords/#comment-167</guid>
					<description>Having a hugely long password seems a bit unnecessary. So far as I can tell, there are only three conditions needed for a good pass.

1) 8 or more characters
2) Not in a dictionary
3) 4 character sets

If someone had a password like this:

abcefghi

.. and the attacker knew it was lowercase only, they'd have to run through, at maximum, this many combinations:

(26)^8 = 208,827,064,576

That's crackable within an hour or two depending on the hardware.

But if someone made a pass like this:

aA224$(*

That's:

(10+26+26+10)^8 or thereabouts. Which is about 3000 times harder to crack, or about 2/3 of a year. In any setting where it matter, presumably people are required to change their pass more than once every 8 months.

If you went hogwild with some of the less common special characters, you could likely get by with a 6 digit pass.</description>
		<content:encoded><![CDATA[	<p>Having a hugely long password seems a bit unnecessary. So far as I can tell, there are only three conditions needed for a good pass.</p>
	<p>1) 8 or more characters<br />
2) Not in a dictionary<br />
3) 4 character sets</p>
	<p>If someone had a password like this:</p>
	<p>abcefghi</p>
	<p>.. and the attacker knew it was lowercase only, they'd have to run through, at maximum, this many combinations:</p>
	<p>(26)^8 = 208,827,064,576</p>
	<p>That's crackable within an hour or two depending on the hardware.</p>
	<p>But if someone made a pass like this:</p>
	<p>aA224$(*</p>
	<p>That's:</p>
	<p>(10+26+26+10)^8 or thereabouts. Which is about 3000 times harder to crack, or about 2/3 of a year. In any setting where it matter, presumably people are required to change their pass more than once every 8 months.</p>
	<p>If you went hogwild with some of the less common special characters, you could likely get by with a 6 digit pass.
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
