We had server-side sessions before. We still do. They accomplish everything you are describing, without requiring every developer to implement an AuthenticatedSession object himself. Look into ActiveRecordStore in action_controller/session/active_record_store.rb.
This discussion is about the recent move to sessions stored in a cookie, and how to secure such sessions. I would suggest you go to Google Groups and read this thread from the beginning to get the background.
I understand the distinction very well. I would suggest that you have
ascribed more capability to 'session' than the semantics of that
facility allow.
What I'm saying is that now you have client side session data, you
have exposed the limited semantics of 'session' and there is an issue
that was simply masked by the server side stores.
Rails has never offered authenticated anything. That's why there is no
standard login mechanism.
Why not switch to session side stores and mask the issue, or implement
an AuthenticatedSession that does what you want it to do (and release
it as a plugin if you so desire). Complex cookie encryption might be
an interesting technical puzzle, but is it really required by default?
It's a question again of where the framework ends and the application
begins. I don't believe that there is justification for foisting
complex default encryption mechanisms on the framework when the
'problem' is that you are using the wrong model. Just use a server
side session store.
Now I may be wrong about 'session'. Perhaps it is a much more complex
object than it appears. Perhaps it should be. That is not for me to
decide.
How, exactly, would you model the login session so as to be immune to
replay attacks with shared-nothing on the server side?
Use a server side session store, not a client side one.
I do have a bigger problem with your statement that "If you haven't
modelled the functionality, then you can't expect to use it." It is
the job of the framework to give developers functionality that they
don't have to model. Otherwise Rails would just punt and say "Here's
how you set and read a cookie. If you want to use sessions, model
them yourself."
Why not go the whole hog and provide us with a default fifteen level
login system with access control lists?
The issue is where the framework ends and the application begins. A
Rails app that just uses the flash and a setting to determine whether
to show the welcome page doesn't need nonces and anti-replay devices.
Perhaps the first job is to step back a little and ask how much you
*really* should stuff into session. What is the job of that little
semi-persistent-hash?
Hi-
Thanks for the levelheaded response. I'm sorry if I was a little inflammatory before. Occupational hazard.
Comments follow.
I understand the distinction very well. I would suggest that you have
ascribed more capability to 'session' than the semantics of that
facility allow.
What I'm saying is that now you have client side session data, you
have exposed the limited semantics of 'session' and there is an issue
that was simply masked by the server side stores.
(snip)
Why not switch to session side stores and mask the issue, or implement
an AuthenticatedSession that does what you want it to do (and release
it as a plugin if you so desire). Complex cookie encryption might be
an interesting technical puzzle, but is it really required by default?
I think we're on the same page here, but maybe coming at it from opposite directions. I think the session abstraction, as exposed by the server-side stores, worked fine. I don't think it was masking anything -- I wouldn't say that every aspect of an application's semantics needs to be captured explicitly in the model. As an abstraction, the server-side stores provided everything that developers needed, even considering sensitive and volatile data (i.e., authentication information).
The problem comes when you try to change the abstraction. Storing sensitive data with an untrusted client is always tricky -- it's the reason that ATM cards are fundamentally more secure than any anonymous e-cash system. "Complex cookie encryption" covers a lot of ground... the HMAC will definitely be required if you want any integrity at all, and some sort of nonce is (provably) required if replayed sessions can hurt you in any way.
However, I think that it is too much to ask of new developers to implement the whole AuthenticatedSession thing (along with the requisite security analysis) themselves. As Robert James pointed out in this thread, security analysis is really tricky -- there are N ways to get it wrong and 1 way to get it right. And forcing developers to consider security at this level isn't too friendly, IMO.
I believe that CookieStore should be either (1) secure against replay attacks by default, or (2) not the default session store. Anything else is asking too much of non-security-aware developers.
I believe that CookieStore should be either (1) secure against replay attacks by default, or (2) not the default session store. Anything else is asking too much of non-security-aware developers.
There are some other very serious security issues with cookie store as
it stands now.
As I said earlier, I'm waiting for a spec and sample app before
working on a full review. If those never happen, I'll eventually post
the sketches that I already have. But I think the community would be
happier with a material "this is how the app can be compromised" over
"theoretically, depending on the implementation, this might be the
problem." Anyway, if I don't here back on those things, I'll post my
notes from conversation - if I do, I'll try to get a full review done.
I like the shared-nothing cookie store as an option, for
performance/scalability reasons. Just document the vulnerability to
replay attacks and maybe add a timestamp to limit how long the cookie
remains valid.
The nonce thing adds a lot of complexity, and if you need to hit
shared storage anyway there's just no point. As far as I'm concerned,
updating a nounce or the actual session data has similar overhead.
I'd prefer a db backed session store replacing the current default.
Ideally it would be automatically created, indexed and purged of stale
data.
The 'someone' was [1] bitsweat aka Jeremy Kemper who works for 37signals where David Heinemeier Hansson is a partner. I suspect they've talked about this...
Koz asked for a security review, Robert James said he might be able to get one, so I wrote a summary of what has been said / done so far. I was trying to be neutral but detailed, so that's why it might seem bland.
+ 1 It sounds like the decision to make cookie store the default was
premature, at best.
By the way, just because this 'feature' is in EdgeRails does not mean
it will make it to a *stable* release, which makes some of the
hand-wringing on periphery of this thread seem a little premature
also.
> How about just NOT changing the default setting to this less secure
> option? Problem solved.
+ 1 It sounds like the decision to make cookie store the default was
premature, at best.
Planting the seed here led to quick ripening and plenty of pesticide.
By the way, just because this 'feature' is in EdgeRails does not mean
it will make it to a *stable* release, which makes some of the
hand-wringing on periphery of this thread seem a little premature
also.
