Re: Session security with cookies

[Till Elsner <till.elsner () uni-duesseldorf de>]

Hi Aaron,

sorry if I didn't define the problem clearly enough. The only thing  
I'm talking about is session cookies, I just want to identify the  
user from login to logout. Short lifetimes for the cookie shouldn't  
be a problem. The environment would be the worst to think of, namely  
the internet. The is why I can't rely on the clients to secure their  
data.
The data are client information in an online shop, so it includes  
some sensible data as well as things like shopping cards. All I want  
is to create cookies that will be unusable for a potential thief,  
since I guess I haven't the means to ensure the cookie won't be  
stolen from the clients computer. So basically my only question is if  
a short lifetime is the only way to protect me (and the client and  
its data) from the misuse of stolen cookies (at least for the time  
after the cookie has expired).

Till

Am 05.12.2007 um 06:04 schrieb Aaron Katz:

> So you're trying to somehow prevent cookies from being stolen, after
> they've been transmitted to the client.  Are you talking about session
> cookies, or about cookies that persist data (sorry, I'm still not
> clear on the scope of the problem)?
>
> If you're trying to solve the problem of stolen session ids, as stored
> in cookies on the user's system, whether in memory or on disk, I'm not
> really sure what you can do.  I mean, there are the standard things of
> marking it secure, so it shouldn't be sent without SSL; giving the
> cookie a short lifetime, so that stealing it is only useful for a
> short period of time; setting the various no-cache settings to keep it
> in RAM (or the page file); and, if the problem space is small enough
> (and the network in which the solution is provided is under strict
> enough control) you may be able to rely on IP addresses and such, but
> these (recommended) tacks only shrink the problem space to what you
> already seem to be considering: the security of an untrusted client.
> And they rely on the client behaving properly - it's always possible
> for a client to intentionally or unintentionally ignore the server's
> directives.
>
> Protecting session cookies with cryptography seems to be trying to
> allow a client to connect to a server and access that server's
> resources, without actually letting the client know the secret (the
> session ID) that identifies the client to the server.  This would
> require sending the session cookie to the client, but not actually
> telling the client the raw session ID.  As I mentioned, before,
> without tightly binding the cookie to the client, in some other way,
> the cookie can simply be replayed from another system.
>
> The only reason I can see for encrypting a session cookie is if the
> server doesn't trust the client - if the security of the client is not
> sufficient to protect the cookie.  But, if the security isn't enough
> to protect the cookie, why would the security be strong enough to
> protect the encrypted/signed cookie?  And, if it's not enough to
> protect the encrypted/signed cookie, why would it be enough to protect
> any data used to tightly bind the cookie to the client?
>
>
>
> If you're trying to solve persistent data, related to the user
> account, but stored on the client system, that problem seems solvable
> via cryptography.  A key could be generated for each user.  A
> particular user's key could be used to encrypt/sign the data before
> sending it to the client as a cookie.  The key could then be used to
> decrypt/check the data when received by the server.  Of course, this
> still requires the server to know which key to use, and still depends
> upon the security of the session.
>
> The big problem with this would be that cryptography is generally
> pretty slow, and servers need to be very responsive.  If every request
> from every client requires the cookie be decrypted, reformed, and
> re-encrypted, this could be a huge drain on the server.  The
> performance penalty would be highly dependent on the information being
> stored in the cookie.  Additionally, it may be simpler to just store
> the data on the server - is there any reason why the information
> cannot be stored server side?
>
>
>
> I guess the problem still needs to be better defined.  What is the
> environment?  Is it the Internet, a home network, or a corporate
> network? What data is being protected?  Is it just a shopping cart, or
> is it something that has extra storage restrictions, such as credit
> cards?  What services does the server provide, and why can't the data
> be stored on the server (of course, if this is the session cookie, the
> answer would be self-evident)?
>
> --
> Aaron
>
>
>
> On Dec 4, 2007 6:48 PM, Till Elsner <till.elsner@uni- 
> duesseldorf.de> wrote:
> > Hi Aaron,
> >
> > the second problem you're mentioning is definitely the one i'm more
> > worrying about. In my eyes generating an ID the not (easily)
> > pedictable is a solvable problem, but a stolen cookie is another
> > thing. I think it would be okay for me to use short-living cookies,
> > but i wonder if this is the only secure way to protect users from
> > suffering from stolen cookies.
> >
> > Till
> >
> > Am 04.12.2007 um 23:13 schrieb Aaron Katz:
> >
> >
> > > Ron,
> > >
> > > It's unclear exactly what problem you're trying to solve.   
> > > Encrypting
> > > & signing the cookie may stop tampering, but it won't prevent  
> > > stealing
> > > the cookie and replaying it.  So, you've basically got two types of
> > > data that might be in the cookie: the session identifier, or the
> > > state.
> > >
> > > In either case, you have to decide whether or not to tie the  
> > > cookie to
> > > the client.  If you don't tie the cookie to the client, (or possibly
> > > the current time, with a very short timeout, and automated
> > > replacement), then nothing prevents replay of the cookie.
> > >
> > > If you tie the cookie to the client, you've got the problem of
> > > uniquely identifying the client.  You've got to use stuff that's
> > > available to the server, so that the server can confirm the cookie.
> > > The obvious ideas would be IP address, user agent, and such, but  
> > > these
> > > don't seem to work very well.  The IP address can be "duplicated"  
> > > for
> > > multiple clients (NAT), and can theoretically change at inopportune
> > > times (DHCP).  User agent agent isn't unique, and provides such  
> > > little
> > > entropy (most people choose from the same small set of browsers (IE,
> > > Fx, Mozilla, Opera, Lynx)) that the dictionary attack to discover it
> > > is so easily overcome that it's probably not worth the effort.
> > >
> > > The problem of uniquely tying the cookie to the client seems to rely
> > > upon the problem of uniquely identifying the client.  Uniquely
> > > identifying the client is what the session cookie is trying to  
> > > solve.
> > > To improve this, you might consider client certificates, but that
> > > comes with its own problems.
> > >
> > > If you're tying the cookie to the current time (directly, by time
> > > stamp, or indirectly, if you choose to include the session  
> > > identifier
> > > in a cookie that contains state), then you have to be sure that the
> > > cookie doesn't contain anything that absolutely must live longer  
> > > than
> > > the timeout.  For example, some shopping carts retain their content,
> > > between multiple sessions.
> > >
> > > Also, in some cases, it may be entirely appropriate to allow  
> > > tampering
> > > (I can't think of one off the top of my head, but it seems like a
> > > reasonable assumption that this would be good, in some cases).
> > >
> > >
> > > As implied, above, it would be easier to comment on your thoughts if
> > > you identify the problem that you're trying to solve :)
> > >
> > > --
> > > Aaron
> > >
> > > On Dec 4, 2007 1:47 PM, Ron <ronlists () skullsecurity com> wrote:
> > > > Something I've recently been toying with is the idea of
> > > > encrypting/signing cookies with a private key on the server. The  
> > > > the
> > > > cookies can't be read or tampered with by the user, nor can they be
> > > > stolen by cross-site attacks and the like.
> > > >
> > > > This isn't something I've done a lot of work with, however, so I
> > > > may be
> > > > missing something obvious, and am open to comments on the idea.
> > > >
> > > > Ron
> > > >
> > > > Till Elsner wrote:
> > > > > Hi, i'm investigating in web application security this time and  
> > > > > i'm
> > > > > trying to find some information about session management with
> > > > > cookies
> > > > > and related security issues. Can anyone point me to tips on how
> > > > > to make
> > > > > cookie based sessions more secure and how to prevent session
> > > > > hijacking?
> > > > > How secure is session handling using cookies and what are the main
> > > > > risks? Is anyone aware of good literature on that topic?
> > > > > Thanks and have a nice day
> > > > > Till
> > > > >
> > > > > ------------------------------------------------------------------ 
> > > > > --
> > > > > -----
> > > > > Sponsored by: WatchfireMethodologies & Tools for Web Application
> > > > > Security AssessmentWith the rapid rise in the number and types of
> > > >
> > > > > security threats, web application security assessments should be
> > > > > considered a crucial phase in the development of any web
> > > > > application.
> > > > > What methodology should be followed? What tools can accelerate the
> > > > > assessment process? Download this Whitepaper today!
> > > > > https://www.watchfire.com/securearea/whitepapers.aspx?
> > > > > id=70170000000940F
> > > > > ------------------------------------------------------------------ 
> > > > > --
> > > > > -----
> > > >
> > > > ------------------------------------------------------------------- 
> > > > --
> > > > ----
> > > > Sponsored by: Watchfire
> > > > Methodologies & Tools for Web Application Security Assessment
> > > > With the rapid rise in the number and types of security threats,
> > > > web application security assessments should be considered a
> > > > crucial phase in the development of any web application. What
> > > > methodology should be followed? What tools can accelerate the
> > > > assessment process? Download this Whitepaper today!
> > > >
> > > > https://www.watchfire.com/securearea/whitepapers.aspx?
> > > > id=70170000000940F
> > > > ------------------------------------------------------------------- 
> > > > --
> > > > ----
> > >
> > > -------------------------------------------------------------------- 
> > > --
> >
> > > ---
> > > Sponsored by: Watchfire
> > > Methodologies & Tools for Web Application Security Assessment
> > > With the rapid rise in the number and types of security threats,
> > > web application security assessments should be considered a crucial
> > > phase in the development of any web application. What methodology
> > > should be followed? What tools can accelerate the assessment
> > > process? Download this Whitepaper today!
> > >
> > > https://www.watchfire.com/securearea/whitepapers.aspx?
> > > id=70170000000940F
> > > -------------------------------------------------------------------- 
> > > --
> > > ---


-------------------------------------------------------------------------
Sponsored by: Watchfire 
Methodologies & Tools for Web Application Security Assessment 
With the rapid rise in the number and types of security threats, web application security assessments should be considered a crucial phase in the development of any web application. What methodology should be followed? What tools can accelerate the assessment process? Download this Whitepaper today! 

https://www.watchfire.com/securearea/whitepapers.aspx?id=70170000000940F
-------------------------------------------------------------------------