Re: Session security with cookies

["Eduardo Tongson" <propolice () gmail com>]

Hello,

The scheme you described is extensively expounded here [1]. The
problems or shortcomings of [1] is discussed in [2] and suggests a
solution. Anyway it is good if the list can add further discussion to
these schemes.

I do not know why most people do not bother reading pertinent resource
linked to. Already sifted through several papers and these two are the
most apposite to the subject. I suggest everybody who has an interest
in web application security or anybody developing websites to read
them.

[1] <http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf>
[2] <http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf>

   Eduardo Tongson

On Dec 7, 2007 5:48 AM, Aaron Shelmire <shelmire () psc edu> wrote:
> Hi all,
>     Not to add another Aaron to the conversation, polluting the
> namespace and all, but my thoughts on the problem at hand.
>
>     I don't see what keeping any of the cookie attributes secret buys
> you. I only see the need to make sure the integrity of the packet is the
> same, and to authenticate that the data came from the server. I also
> don't see any reason why there needs to be a key known by the client, or
> why there needs to be a key assigned to the client.
>
>     As a proposal to resolve this, consider the following.
>     For the example cookie without protection we have the attributes
>
>     SessionID
>     TimestampServer
>     ItemPrice
>     ItemQuantity
>     ItemID
>     OtherData
>
>     Suppose we want to be able to deliver that information in the
> cookie, without worrying about the ItemPrice being changed and that the
> item price is still tied to the correct item. We also want to make the
> cookie short lived, which will require us to rely upon the
> TimestampServer field which we want to assure will not be altered. We
> don't want the sessionID to be changed. The entity that is generating
> this data, and the entity that is checking the data as it receives it to
> assure it hasn't been changed are one and the same. So why not use a
> message authentication code such that the cookie is now...
>
>     SessionID
>     TimestampServer
>     ItemPrice
>     ItemQuantity
>     ItemID
>     OtherData
>     MAC( SessionID, TimestampServer, ItemPrice, ItemQuantity) under
> KeyServer.
>
>     The server now only needs to keep the key a secret locally, and
> doesn't need to share it. Additionally MAC's are created using symmetric
> key encryption, meaning the operation is much faster than the encryption
> under the public key, and encryption under the private key(the
> signature). It may not be as fast as a hash but a hash doesn't tie the
> hashing function to any entity. The hashing function would be publicly
> known, and therefore anyone could take the cookie, edit the data, and
> generate a new hash. Whereas a MAC is only generated by those who know
> the secret key.
>
>     We still allow the client to read all of the data in the cookie.
> Furthermore some information may still be edited, such as the ItemQuantity.
>
>     Now suppose we want to tie this cookie to a particular Client and
> Server (and therefore don't want that information to be altered), This
> can be simply acheived with by adding information to specifically name
> that client and to identify the server for which it is bound such that
> the cookie now contains
>
>     ClientID
>     ServerID
>     SessionID
>     TimestampServer
>     ItemPrice
>     ItemQuantity
>     ItemID
>     OtherData
>     MAC( ClientID, ServerID, SessionID, TimestampServer, ItemPrice,
> ItemQuantity) under KeyServer.
>
>     Where ClientID is whatever you decide is best (perhaps userid
> concatenated with IP). The same with ServerID. Although I may have just
> screwed this up, since the ServerID can't be verified by client since it
> doesn't share the key used to verify the MAC. Although I know there was
> a reason I thought of it this way but have forgotten now. (I hatched
> this plan while riding and as such didn't write it down). There Server
> can identity that the data was bound for it, although it is able to do
> that via verification of the MAC so long as the secret key is only known
> by it and the encryption algorithm is secure (which if either is not the
> entire scheme fails).
>
> Thoughts?
>
>
> -aaron
>
>
>
> Aaron Katz wrote:
> > Till,
> >
> > Thank you for the clarification.  There's another important question
> > to answer: does the experience have to be a standard, transparent
> > experience, or can you be a little more visible to the user?  If you
> > don't mind being less transparent, you could require the user run some
> > additional software on their system.  For example, you could implement
> > your site in Flash, then use the Flash applet to tightly bind to the
> > user's system.  Of course, an insecure client running malware will
> > still be able to intercept the session cookie, but the flash client
> > could require certain software be running, such as antivirus software.
> >
> > There are problems with this, of course.  There is some set of users
> > (like myself) who don't run anything with flash - if I go to a website
> > that is implemented in flash, I make every effort to go to a
> > competitor.  There's also a concern of privacy - the flash applet will
> > need to bind itself to the client, in a manner that the server can
> > confirm, without providing that private information to the server.  Of
> > course, malware can identify those same bindings, and an attacker can
> > use a virtualized environment (with some effort) to reproduce those
> > bindings.  And there's the consideration that, if you're forcing
> > customers to run additional software (AV software), your customers may
> > not want to spend the time and money to on such software, and you may
> > drive away business.
> >
> > You either have to trust your client, or not accept connections from
> > that client.  Someone smarter than myself might be able to solve this
> > for you, but I don't see any way to trust a client with access while
> > not trusting them with any way to gain access.
> >
> > Then, there's the consideration that we're focusing on a very small
> > part of the whole picture.  The session cookie is just like the user's
> > password, where stealing it would give the attacker access, but it's
> > not the only way to mitigate risk - and the degree of risk hasn't even
> > been identified.  What is the liklihood that the software will be
> > attacked?  What is the value of the software being attacked?  What is
> > the value of that which it protects?  What are the real risks involved
> > in a stolen session cookie?  Is this an administrator's session cookie
> > (where you _can_ add/recommend restrictions on sanitary browsing and
> > hardened systems) or is it strictly user machines, which you cannot
> > control?  Are there any other means to mitigate risk (audit logs,
> > IDS/IPS, canceling orders, blocking known bad IP blocks at the router,
> > requiring acceptance of customer agreements, only sign up customers
> > that etc.)?
> >
> > In the end, either you'll need to come up with an entirely new
> > paradigm, or I think you'll need to further analyze (and quantify)
> > this particular risk, and either accept it or find other ways to
> > mitigate it.
> >
> > --
> > Aaron
> >
> >
> > On Dec 5, 2007 5:48 AM, Till Elsner <till.elsner () uni-duesseldorf de> wrote:
> >
> > > 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
> > -------------------------------------------------------------------------
>
>
> -------------------------------------------------------------------------
>
> 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
-------------------------------------------------------------------------