Jim Lindley Notes

Ruby on Rails Security has a great article on cookie-based session storage. This is the default for Rails 2.0, and if you generate a new Rails app it will create a very long random string to use for hashing the cookie to prevent tampering. This seems to be fairly secure, although it’s always safest to switch to a server based session storage mechanism.

If you are converting your pre-2.0 app to use cookie based sessions, you must be careful to pick a very good secret for the hashing function. And ‘good’ means computer generated, very long, very random, and no dictionary words. Rails will now prevent you from using a secret less then 30 characters long.

If you are only storing a minimal amount of information in the session (such as a user id and flash message), cookie session store is an awesome win. Otherwise, you’re probably using it wrong: no sensitive information should be placed in session, and if you need to expire sessions, you must place an expiration time in the session and check that per request and decide if you’ll accept it still.

UPDATE: More info on cooke session store security.