764 Responseshttp%3A%2F%2Fblog.phishme.com%2F2007%2F11%2Fowning-rails-20-cookies-at-owasp-part-ii%2FOwning+Rails+2.0+Cookies+at+OWASP%3A+Part+II2007-11-19+19%3A05%3A08Coreyhttp%3A%2F%2Fblog.phishme.com%2F2007%2F11%2Fowning-rails-20-cookies-at-owasp-part-ii%2F to “Owning Rails 2.0 Cookies at OWASP: Part II”

1. PhishMe » Owning Rails 2.0 Cookies at OWASP says:

   November 19, 2007 at 2:16 pm

   [...] See the “Part II” post for the BustRailsCookie script. Digg [...]
2. Jeremy Kemper says:

   November 20, 2007 at 12:50 pm

   I'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'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.
3. Jeremy Kemper says:

   November 20, 2007 at 2:17 pm

   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.
4. b3nn says:

   November 21, 2007 at 3:56 am

   Here's a link to the rails-core mailing list where this topic is continued.

   http://groups.google.com/group/rubyonrails-core/b…

   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's probably ways to fix that.) We seem to be in disagreement that this should be the default session store choice.