4 ms·

Does anyone have anything to add about the security of this: Action Pack: Cookie store sessions The default session store in Rails 2.0 is now a cookie-based o

Does anyone have anything to add about the security of this: Action Pack: Cookie store sessions The default session store in Rails 2.0 is now a cookie-based one. That means sessions are no longer stored on the file system or in the database, but kept by the client in a hashed form that can't be forged. This makes it not only a lot faster than traditional session stores, but also makes it zero maintenance. There's no cron job needed to clear out the sessions and your server won't crash because you forgot and suddenly had 500K files in tmp/session. This setup works great if you follow best practices and keep session usage to a minimum, such as the common case of just storing a user_id and a the flash. If, however, you are planning on storing the nuclear launch codes in the session, the default cookie store is a bad deal. While they can't be forged (so is_admin = true is fine), their content can be seen. If that's a problem for your application, you can always just switch back to one of the traditional session stores (but first investigate that requirement as a code smell).

deleted 19y ago
[deleted]
qaexl 19y ago
Yeah. There was a discussion about it in an earlier thread. Unfortunately, I can't seem to find it anymore. If you look at the code, the session store is stored in plaintext with the hash. Rails rehashes the plaintext in the cookie and checks it against the hash to make sure it has not been tampered with. The last time I checked, the hashing uses OpenSSL's HMAC hashing rather than the SHA1 in earlier versions of Rails. You, as the developer, are responsible for entering in the site's secret code. It should be possible to write a Rails 2.0 initializer in config/intializer to check the presence of config/secret.yml and if not, generate it in runtime. This keeps you from having to save the secret in the version control, but unfortunately, doesn't work well when you deploy it across several machines. Note that the cookie store was available in 1.2. Seems as if the core developers like it enough to enable it by default. As for me, I think I'll stick with ActiveStore for a while until my sites needs more drastic means, such as memcached or even cookie store.
- carpal 19y ago
  Heres the thread: http://news.ycombinator.com/item?id=81932 http://news.ycombinator.com/item?id=81932

deleted 19y ago

[deleted]

qaexl 19y ago

Yeah. There was a discussion about it in an earlier thread. Unfortunately, I can't seem to find it anymore. If you look at the code, the session store is stored in plaintext with the hash. Rails rehashes the plaintext in the cookie and checks it against the hash to make sure it has not been tampered with. The last time I checked, the hashing uses OpenSSL's HMAC hashing rather than the SHA1 in earlier versions of Rails. You, as the developer, are responsible for entering in the site's secret code. It should be possible to write a Rails 2.0 initializer in config/intializer to check the presence of config/secret.yml and if not, generate it in runtime. This keeps you from having to save the secret in the version control, but unfortunately, doesn't work well when you deploy it across several machines. Note that the cookie store was available in 1.2. Seems as if the core developers like it enough to enable it by default. As for me, I think I'll stick with ActiveStore for a while until my sites needs more drastic means, such as memcached or even cookie store.

carpal 19y ago
Heres the thread: http://news.ycombinator.com/item?id=81932 http://news.ycombinator.com/item?id=81932