Forum: Ruby on Rails Security risks of cookie-based session storage

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Eric L. (Guest)
on 2009-02-22 01:17
(Received via mailing list)
Should I be concerned if I am using the default cookie-based session
storage for a high security application?  Nothing sensitive will be
stored on the cookie, but it's critical that one user cannot gain
access to another user's account.  The security risks I see with
cookie-based storage are:

1. There is a single point of failure.  If the secret key is stolen
(for example, by a rogue developer), the person in possession of the
key can log into any account he wishes.

2. It's not been as widely used as database-backed session, and
therefore not as tested.

3. The cryptographic algorithm could be compromised, which is always a
possibility (however unlikely.)

What do you think?

Eric
Frederick C. (Guest)
on 2009-02-22 01:21
(Received via mailing list)
On Feb 21, 5:06 pm, "Eric L." <removed_email_address@domain.invalid> wrote:
> 2. It's not been as widely used as database-backed session, and
> therefore not as tested.
>

given that it's been the default for well over a year I would question
that.

> 3. The cryptographic algorithm could be compromised, which is always a
> possibility (however unlikely.)
>

While the risks in 1 and 3 do exist I don't think it's a game changer
compared to the other risks involved (people setting weak passwords,
the cryptographic algorithm securing your ssh or ssl sessions being
compromised and data being leaked that way, the rogue developer
harvesting data straight from the database, cookies being stolen via
XSS attacks etc.)

Fred
Eric L. (Guest)
on 2009-02-24 04:31
(Received via mailing list)
Good point.  I realized risk #1 could be reduced by storing the secret
in a secure place on the deployment server rather than under source
control.

On Feb 21, 3:20 pm, Frederick C. <removed_email_address@domain.invalid>
This topic is locked and can not be replied to.