<?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: Owning Rails 2.0 Cookies at OWASP: Part II</title>
	<atom:link href="http://blog.phishme.com/2007/11/owning-rails-20-cookies-at-owasp-part-ii/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.phishme.com/2007/11/owning-rails-20-cookies-at-owasp-part-ii/</link>
	<description>Internet Security Professionals comment on innovative phishing ploys, social engineering techniques, and the latest hacks. Bashing or bowing to the latest and greatest news in the security community. Keep up to speed with what phishers, hackers, and spammers are doing or just listen in on the latest geek rants. PhishMe is your one stop blog for the latest in anti-phishing and security news.</description>
	<lastBuildDate>Fri, 26 Feb 2010 10:25:13 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: b3nn</title>
		<link>http://blog.phishme.com/2007/11/owning-rails-20-cookies-at-owasp-part-ii/comment-page-1/#comment-70</link>
		<dc:creator>b3nn</dc:creator>
		<pubDate>Wed, 21 Nov 2007 13:56:54 +0000</pubDate>
		<guid isPermaLink="false">http://blog.phishme.com/2007/11/owning-rails-20-cookies-at-owasp-part-ii/#comment-70</guid>
		<description>Here&#039;s a link to the rails-core mailing list where this topic is continued. 

http://groups.google.com/group/rubyonrails-core/browse_thread/thread/769f64d0f4ad59af

To wrap up where things currently stand: Yes, the brute forcing of the cookie store hash is possible like this script demonstrates (so choose a strong password everyone!) And session replay is also possible (but there&#039;s probably ways to fix that.) We seem to be in disagreement that this should be the default session store choice.</description>
		<content:encoded><![CDATA[<p>Here&#8217;s a link to the rails-core mailing list where this topic is continued. </p>
<p><a href="http://groups.google.com/group/rubyonrails-core/browse_thread/thread/769f64d0f4ad59af" rel="nofollow">http://groups.google.com/group/rubyonrails-core/browse_thread/thread/769f64d0f4ad59af</a></p>
<p>To wrap up where things currently stand: Yes, the brute forcing of the cookie store hash is possible like this script demonstrates (so choose a strong password everyone!) And session replay is also possible (but there&#8217;s probably ways to fix that.) We seem to be in disagreement that this should be the default session store choice.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeremy Kemper</title>
		<link>http://blog.phishme.com/2007/11/owning-rails-20-cookies-at-owasp-part-ii/comment-page-1/#comment-68</link>
		<dc:creator>Jeremy Kemper</dc:creator>
		<pubDate>Wed, 21 Nov 2007 00:17:23 +0000</pubDate>
		<guid isPermaLink="false">http://blog.phishme.com/2007/11/owning-rails-20-cookies-at-owasp-part-ii/#comment-68</guid>
		<description>Correction: the cracker itself does use the HMAC. All the other links are wrong. The concern regarding session secret strength is totally valid. See the discussion on the rails-core mailing list for more.</description>
		<content:encoded><![CDATA[<p>Correction: the cracker itself does use the HMAC. All the other links are wrong. The concern regarding session secret strength is totally valid. See the discussion on the rails-core mailing list for more.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeremy Kemper</title>
		<link>http://blog.phishme.com/2007/11/owning-rails-20-cookies-at-owasp-part-ii/comment-page-1/#comment-66</link>
		<dc:creator>Jeremy Kemper</dc:creator>
		<pubDate>Tue, 20 Nov 2007 22:50:48 +0000</pubDate>
		<guid isPermaLink="false">http://blog.phishme.com/2007/11/owning-rails-20-cookies-at-owasp-part-ii/#comment-66</guid>
		<description>I&#039;m sorry to report that you spread FUD at the OWASP conference.

Remove the rev query parameter from the link to the cookie store source, or simply checkout Rails trunk anytime since March 3 2007, and reconsider your claim.

I find this lack of diligence inexcusable when it&#039;s the basis for a talk at a security conference. Please consider correcting this and your earlier post.

There are legitimate concerns with the cookie store, but brute force attacks are not one of them.</description>
		<content:encoded><![CDATA[<p>I&#8217;m sorry to report that you spread FUD at the OWASP conference.</p>
<p>Remove the rev query parameter from the link to the cookie store source, or simply checkout Rails trunk anytime since March 3 2007, and reconsider your claim.</p>
<p>I find this lack of diligence inexcusable when it&#8217;s the basis for a talk at a security conference. Please consider correcting this and your earlier post.</p>
<p>There are legitimate concerns with the cookie store, but brute force attacks are not one of them.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: PhishMe &#187; Owning Rails 2.0 Cookies at OWASP</title>
		<link>http://blog.phishme.com/2007/11/owning-rails-20-cookies-at-owasp-part-ii/comment-page-1/#comment-63</link>
		<dc:creator>PhishMe &#187; Owning Rails 2.0 Cookies at OWASP</dc:creator>
		<pubDate>Mon, 19 Nov 2007 19:16:40 +0000</pubDate>
		<guid isPermaLink="false">http://blog.phishme.com/2007/11/owning-rails-20-cookies-at-owasp-part-ii/#comment-63</guid>
		<description>[...] See the &#8220;Part II&#8221; post for the BustRailsCookie script. Digg [...]</description>
		<content:encoded><![CDATA[<p>[...] See the &#8220;Part II&#8221; post for the BustRailsCookie script. Digg [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.433 seconds -->
