Re: Cookie-based sessions: why HMAC?

On Mar 21, 2007, at 9:28 PM, Steven A Bristol wrote:

>
>
> >
> > The typical session stores a handful of
utilitarian info: a  
> user_id, a
> > flash message, and perhaps a return URL. You
shouldn't, and needn't,
> > use the session for confidential data.
> >
> > I consider exposing these data (however
obfuscated) as statement of
> > the reasonable bounds of session usage.
>
> Storing the user_id in a cookie is exactly the sort of
security  
> hole that does concern me. What steps have been taken
to ensure  
> that the data cannot be tampered?
>

The HMAC ensures that. (http://en.wikipedia
.org/wiki/HMAC) If the  
user tampers with the data, the MAC verification fails and
the server  
rejects the session.

This discussion is about situations where confidentiality
might be  
required -- where you might want to store something in the
session  
that you don't want the user to be able to read.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

> Storing the user_id in a cookie is exactly the sort of
security hole that
> does concern me. What steps have been taken to ensure
that the data cannot
> be tampered?

That's what the HMAC is for,  if you tamper with the data,
the hash is
no longer correct.

http://en.wikipedia
.org/wiki/Hmac

> I also agree that rails should be secure by default. If
the data is in text
> format, then I think session cookies by default is an
unwise choice.

I don't believe there's a single person on this list who
thinks we
should ship security bugs.  If there's a genuine problem
with the
cookie store, we'll take the actions needed to clean it up.

> Steven A Bristol
>
>
>  >
>


-- 
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On 3/21/07, Steven A Bristol <stevenbristolgmail.com> wrote:
> > > The typical session stores a handful of
utilitarian info: a user_id, a
> > > flash message, and perhaps a return URL. You
shouldn't, and needn't,
> > > use the session for confidential data.
> > >
> > > I consider exposing these data (however
obfuscated) as statement of
> > > the reasonable bounds of session usage.
>
> Storing the user_id in a cookie is exactly the sort of
security hole that
> does concern me. What steps have been taken to ensure
that the data cannot
> be tampered?
>

guid field instead of database IDs will mitigate some of
your concerns

    user = User.find_by_guid(session[:user_id])


court3nay

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---