Rails - Jan 2006 - Can the session be trusted for Username/password?

I understand that a session is server side, and not externally visible. 
For this reason can it be used to store a User class (username/ hashed 
password) safely?

Or do I need to check whats in the session against the user table every 
time I access a controller?

Many thanks, P.

-- 
Posted via http://www.ruby-forum.com/.

I''m not sure what the Rails philosophy is on this, but I typically just
check for a :login attribute in my session hash and if it doesn''t
exist,
redirect the user to a login controller in order to authenticate them.

I''d also love to hear if there''s a better or more secure way
to do this.

-Will

On 1/19/06, Phil <phil@nospam.com> wrote:
>
> I understand that a session is server side, and not externally visible.
> For this reason can it be used to store a User class (username/ hashed
> password) safely?
>
> Or do I need to check whats in the session against the user table every
> time I access a controller?
>
> Many thanks, P.
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060119/fa95b2b0/attachment.html

Seems ok to me.  If you''re not storing the User object, you''d
need to
store *something* in there to remember their credentials anyway.  Either
way, your session data is critical to your security.

As with all security, it''s a trade off.  Checking the database makes it
more difficult for an attacker who can modify session data somehow, but
it''s an extra database query each time.

I''m confident enough that my code won''t allow an attacker to
modify
session data.  I think I''d have to really fsck up for that to happen.

John.

On Thu, 2006-01-19 at 22:04 +0100, Phil wrote:
> I understand that a session is server side, and not externally visible. 
> For this reason can it be used to store a User class (username/ hashed 
> password) safely?
> 
> Or do I need to check whats in the session against the user table every 
> time I access a controller?
> 
> Many thanks, P.
>

Phil <phil@...> writes:
> I understand that a session is server side, and not externally visible. 
> For this reason can it be used to store a User class (username/ hashed 
> password) safely?
> 
> Or do I need to check whats in the session against the user table every 
> time I access a controller?
You''re correct, session data only exists on the server, so
it''s safe, so you can
store whatever is convienient in it for identifying authenticated users.

On the other hand, the way you map users to session data is via a key that is
stored in a cookie on the client side, and that key is transmitted over the
network in the clear (unless you''re using https), so the session key is
a
possible source of mischief.  For example, there are attacks where the attacker
tries to intercept the user''s session key in transit, or off the
user''s machine,
and then uses it to masquerade as that user.  There are also "session
fixation"
attacks (see AWDR p. 445-446, and
http://www.windowsecurity.com/whitepaper/uplarticle/11/session_fixation.pdf)
that you have to watch out for.

If you''re worried about these kinds of attacks there are some simple
things you
can do; for example:

* Delete session data (reset_session) when the user logs out, so their session
key can''t be used again.

* Store the user''s IP address in their session hash; every time invoke
a
controller, verify that their current IP address (request.remote_ip) matches
what the session hash says it should be. This prevents (or at least, makes it
more difficult) for someone who intercepts the key to use it.

* Store an expiration date/time in the session; when a controller is invoked,
check that the session hasn''t expired; again, this just makes life more
difficult for an attacker.

--Forrest

Thanks for the replies. That really clears that up - and the possible 
secuirty concerns!

I was hoping to allow login, then put the user object in the session and 
from then on just refrence the session.

Once an object is in a session, can its methods still be called
eg.

@session[:user] = @user.find(1)
is_logged_in = @session[:user].logged_in?

Thanks P.


Forrest Thiessen wrote:
> Phil <phil@...> writes:
> 
>> I understand that a session is server side, and not externally visible.
>> For this reason can it be used to store a User class (username/ hashed 
>> password) safely?
>> 
>> Or do I need to check whats in the session against the user table every
>> time I access a controller?
> 
> You''re correct, session data only exists on the server, so
it''s safe, so
> you can
> store whatever is convienient in it for identifying authenticated users.
> 
> On the other hand, the way you map users to session data is via a key 
> that is
> stored in a cookie on the client side, and that key is transmitted over 
> the
> network in the clear (unless you''re using https), so the session
key is
> a
> possible source of mischief.  For example, there are attacks where the 
> attacker
> tries to intercept the user''s session key in transit, or off the
user''s
> machine,
> and then uses it to masquerade as that user.  There are also "session 
> fixation"
> attacks (see AWDR p. 445-446, and
>
http://www.windowsecurity.com/whitepaper/uplarticle/11/session_fixation.pdf)
> that you have to watch out for.
> 
> If you''re worried about these kinds of attacks there are some
simple
> things you
> can do; for example:
> 
> * Delete session data (reset_session) when the user logs out, so their 
> session
> key can''t be used again.
> 
> * Store the user''s IP address in their session hash; every time
invoke a
> controller, verify that their current IP address (request.remote_ip) 
> matches
> what the session hash says it should be. This prevents (or at least, 
> makes it
> more difficult) for someone who intercepts the key to use it.
> 
> * Store an expiration date/time in the session; when a controller is 
> invoked,
> check that the session hasn''t expired; again, this just makes life
more
> difficult for an attacker.
> 
> --Forrest

-- 
Posted via http://www.ruby-forum.com/.