4 ms·

I don't think requiring that your user(s) be compromised before this becoming an issue is a valid defence. Especially when cookies are easily stolen using somet

I don't think requiring that your user(s) be compromised before this becoming an issue is a valid defence. Especially when cookies are easily stolen using something like Firesheep or as simple as forgetting to logout of a public terminal. You should ultimately be putting in systems that, if in the event of a compromise, you can mitigate the cost to the user.

danielweber 13y ago
I recognize this fight. Person A has a system, person B finds a problem in it. Now, is it a "real" problem? Emotions run high, on both sides, and I've been on both sides of it at various points in my life. I recognize the patterns of the bad arguments made by both sides (by A: "of course you don't do that," "this requires something else bad to happen," "that's a problem with bad coders", "you are an idiot"; and by B: "every potential issue is worth full attention," "you should always stop your developers from breaking things," "you can't fix things with obscurity!!!1," "you'll be sorry", "you are an idiot.").
thibaut_barrere 13y ago
Just to clarify, in case this is needed: I totally agree. Just posted that to bring fuel to the discussion. My hope is that expiration will be soon baked-in (or easier to bake in), after reading https://github.com/rails/rails/pull/11168 https://github.com/rails/rails/pull/11168
sneak 13y ago
> Especially when cookies are easily stolen using something like Firesheep Who in late 2013 (with enough clue to care about this issue) is still using non-secure-flag cookies for anything even remotely important?!
- damncabbage 13y ago
  As far as I'm Rails doesn't use secure-flag cookies by default; you need to have something like this in config/initializers/session_store.rb: local_env = !(Rails.env.test? || Rails.env.development?) MyApp::Application.config.session_store(:cookie_store, { key: '_my_app_session', secure: local_env, # ... or just true }) Yes, somebody who has gone looking for this can find it, but I'd argue that Rails should at least give you the secure: ... option in a comment block. Anything less is just inviting people to get bitten by the lack of it.
  - thijsc 13y ago
    You can set config.force_ssl = true to easily enable secure session cookies and strict transport security amongst other things.
cheald 13y ago
> You should ultimately be putting in systems that, if in the event of a compromise, you can mitigate the cost to the user. Completely agreed - that's the gist of the DB bits there. Right now, you can terminate a compromised AR-backed session by logging out, but if you lose that session ID, then you have no control over the compromised session. If someone jacks your SID while you're on a public terminal, using ARStore alone isn't going to save you.

danielweber 13y ago

I recognize this fight. Person A has a system, person B finds a problem in it. Now, is it a "real" problem? Emotions run high, on both sides, and I've been on both sides of it at various points in my life. I recognize the patterns of the bad arguments made by both sides (by A: "of course you don't do that," "this requires something else bad to happen," "that's a problem with bad coders", "you are an idiot"; and by B: "every potential issue is worth full attention," "you should always stop your developers from breaking things," "you can't fix things with obscurity!!!1," "you'll be sorry", "you are an idiot.").

thibaut_barrere 13y ago

Just to clarify, in case this is needed: I totally agree. Just posted that to bring fuel to the discussion. My hope is that expiration will be soon baked-in (or easier to bake in), after reading https://github.com/rails/rails/pull/11168 https://github.com/rails/rails/pull/11168

sneak 13y ago

> Especially when cookies are easily stolen using something like Firesheep Who in late 2013 (with enough clue to care about this issue) is still using non-secure-flag cookies for anything even remotely important?!

damncabbage 13y ago
As far as I'm Rails doesn't use secure-flag cookies by default; you need to have something like this in config/initializers/session_store.rb: local_env = !(Rails.env.test? || Rails.env.development?) MyApp::Application.config.session_store(:cookie_store, { key: '_my_app_session', secure: local_env, # ... or just true }) Yes, somebody who has gone looking for this can find it, but I'd argue that Rails should at least give you the secure: ... option in a comment block. Anything less is just inviting people to get bitten by the lack of it.
- thijsc 13y ago
  You can set config.force_ssl = true to easily enable secure session cookies and strict transport security amongst other things.

cheald 13y ago

> You should ultimately be putting in systems that, if in the event of a compromise, you can mitigate the cost to the user. Completely agreed - that's the gist of the DB bits there. Right now, you can terminate a compromised AR-backed session by logging out, but if you lose that session ID, then you have no control over the compromised session. If someone jacks your SID while you're on a public terminal, using ARStore alone isn't going to save you.