<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Secure your PASSWORD</title>
	<atom:link href="http://www.securetoday.net/2009/02/secure-your-password/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.securetoday.net/2009/02/secure-your-password/</link>
	<description>Protecting your own for the future</description>
	<lastBuildDate>Sat, 17 Jul 2010 04:12:12 -0600</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Angel</title>
		<link>http://www.securetoday.net/2009/02/secure-your-password/comment-page-1/#comment-40</link>
		<dc:creator>Angel</dc:creator>
		<pubDate>Sat, 20 Feb 2010 14:43:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.securetoday.net/?p=57#comment-40</guid>
		<description>Thank you.. That&#039;s good !</description>
		<content:encoded><![CDATA[<p>Thank you.. That&#8217;s good !</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rex</title>
		<link>http://www.securetoday.net/2009/02/secure-your-password/comment-page-1/#comment-38</link>
		<dc:creator>Rex</dc:creator>
		<pubDate>Wed, 17 Feb 2010 20:38:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.securetoday.net/?p=57#comment-38</guid>
		<description>Very true, all passwords will eventually be cracked. It is just a matter of time. So the password itself is no longer what we need to focus on now. But &quot;time&quot;. The more complicated it is, the longer it will take for someone to crack it. Resetting or changing it often is a very good practice. This is also &quot;time&quot; driven as you are giving the cracker no time to figure out the correct password. Tokens are very good complements of passwords. Using a time- or challenged-based tokens appended to your existing password makes it harder for the password to be cracked. Because even though they have figured out your actual password, if they don&#039;t have the token to generate additional randomness, it is still an invalid password to the system.</description>
		<content:encoded><![CDATA[<p>Very true, all passwords will eventually be cracked. It is just a matter of time. So the password itself is no longer what we need to focus on now. But &#8220;time&#8221;. The more complicated it is, the longer it will take for someone to crack it. Resetting or changing it often is a very good practice. This is also &#8220;time&#8221; driven as you are giving the cracker no time to figure out the correct password. Tokens are very good complements of passwords. Using a time- or challenged-based tokens appended to your existing password makes it harder for the password to be cracked. Because even though they have figured out your actual password, if they don&#8217;t have the token to generate additional randomness, it is still an invalid password to the system.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Angel</title>
		<link>http://www.securetoday.net/2009/02/secure-your-password/comment-page-1/#comment-36</link>
		<dc:creator>Angel</dc:creator>
		<pubDate>Sun, 14 Feb 2010 20:19:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.securetoday.net/?p=57#comment-36</guid>
		<description>Any kind of passwords, no matter how complex it is  [with alpha, alpha numeric, alpha number + special characters] it can be cracked using brute force technique.  So what would be your best advise to protect the passwords - Is resetting pwd frequently the only solution or what according to you is the best ?</description>
		<content:encoded><![CDATA[<p>Any kind of passwords, no matter how complex it is  [with alpha, alpha numeric, alpha number + special characters] it can be cracked using brute force technique.  So what would be your best advise to protect the passwords &#8211; Is resetting pwd frequently the only solution or what according to you is the best ?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Petrie P.</title>
		<link>http://www.securetoday.net/2009/02/secure-your-password/comment-page-1/#comment-6</link>
		<dc:creator>Petrie P.</dc:creator>
		<pubDate>Sun, 19 Jul 2009 18:45:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.securetoday.net/?p=57#comment-6</guid>
		<description>Thanks for this. It&#039;s informative.</description>
		<content:encoded><![CDATA[<p>Thanks for this. It&#8217;s informative.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Zarex dela Cruz</title>
		<link>http://www.securetoday.net/2009/02/secure-your-password/comment-page-1/#comment-4</link>
		<dc:creator>Zarex dela Cruz</dc:creator>
		<pubDate>Tue, 14 Jul 2009 21:22:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.securetoday.net/?p=57#comment-4</guid>
		<description>One of the countermeasure I failed to include for security professionals in their corporate world is the implementation of &quot;clipping level&quot;, where you set the threshold for invalid failed login attempts. This will counter any dictionary or brute-force attacks. On the contrary, accounts that exceeds these thresholds set will disable their account, which is an availability issue. Something you need to look into.</description>
		<content:encoded><![CDATA[<p>One of the countermeasure I failed to include for security professionals in their corporate world is the implementation of &#8220;clipping level&#8221;, where you set the threshold for invalid failed login attempts. This will counter any dictionary or brute-force attacks. On the contrary, accounts that exceeds these thresholds set will disable their account, which is an availability issue. Something you need to look into.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
