To split some technical hairs, According to Peepcode's Rails 2.0 pdf, Rails then uses OpenSSL::HMAC hashing. According to the source code cited by the article,

To split some technical hairs, According to Peepcode's Rails 2.0 pdf, Rails then uses OpenSSL::HMAC hashing. According to the source code cited by the article, http://dev.rubyonrails.org/browser/trunk/actionpack/lib/action_controller/session/cookie_store.rb?rev=6184 http://dev.rubyonrails.org/browser/trunk/actionpack/lib/acti... it generates a SHA512 digest with the secret key. The marshal() method includes both an encoded cleartext and the SHA512 digest for "integrity checks". Note that the HEAD revision is r6424, not r6184; r6424 uses the HMAC digest, but still includes both the plaintext and the hashed version with an integrity check. I don't know enough about the relative merits of HMAC vs. SHA512 hashing. I do know it still depends on the developer remembering to change the secret key into something harder to crack. This isn't exactly a Rails 2.0 thing, though. Cookie-based session store was merged in in Rails 1.2.x, but enabled by default in Rails 2.0. You can still use memcached or "ActiveStore". This security vulnerability is probably going to be one of the biggest gotcha for a newbie developer, as there is a wave of inexperienced or irresponsible Rails developers getting in on the action. Newcomers are still looking at the old, "write a blog in 15 minute" video made during the Rails 0.3 days, or the O'Reilly "Write a cookbook Rails app, parts one of three". Or Agile Web Development with Rails, 2nd Ed., which does not mention this gotcha. One solution to this problem is not to depend on the developer to think up or generate a password. Rails 2.0 allows you to write "initializer" snippets that automatically load when placed in the appropriate directory. It would be almost trivially easy to write such a snippet that loads the secret key from an configuration file, and if one does not exist, automatically generate it. Such a setup would not depend on saving the secret key into the version control system, and can be refreshed every time the app gets deployed using an automation tool such as Capistrano. Though it would (should) invalidate all the current user sessions once redeployed. Under this setup, you definitely don't want to serialize objects into the session. That's a surprisingly popular practice among a small minority of Rails developers.