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_at_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_at_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_at_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_at_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
-------------------------------------------------------------------------
Received on Dec 08 2007
Intro
