Penetration Testing mailing list archives

Re: [PEN-TEST] IE Cookie Crypt-Analysis - Good or Bad


From: "Ng, Kenneth (US)" <kenng () KPMG COM>
Date: Tue, 19 Dec 2000 12:56:37 -0500

I agree with this completely.  One should not have sensitive information
stored in cookies.  Cookies should only be used for session markers.  I have
seen one application that used cookies to store the user priviledge.  When I
showed them what I could do with a modified cookie (id = "sa" instead of the
normal user) they changed the scheme.  I recommended that the cookie contain
an index into a very sparse database to make brute forcing the cookie
difficult, along with a cookie expiration.  "current" cookies were in the
database, as well as cookies up to twice the "expiration" value.  In that
way they could tune the expiration to the actual user usage.  Anything over
twice or not in the array was counted as a possible hack attempt.  A bad
cookie count of over XXX in YYY time resulted in a warning message to the
admins.

If I had to do it again, I'd be tempted to have part of the cookie to be a
variation of a digital signature.  For example the last 6 bytes of a 100
byte cookie would be substr(md5(secret_data + cookie),2,6).  Assuming no one
could reverse engineer the secret_data from the md5 hash and cookie value,
this should be a reasonable way to determine if someone is trying to brute
force the cookie values.  Security by obscurity?  Maybe a little bit.  But
even with the algorithm it should be difficult to crack.

-----Original Message-----
From: Fricke, Gregory D. [mailto:Gregory.Fricke () GLOBALINTEGRITY COM]
Sent: Tuesday, December 19, 2000 10:06 AM
To: PEN-TEST () SECURITYFOCUS COM
Subject: Re: [PEN-TEST] IE Cookie Crypt-Analysis - Good or Bad


I agree with Mark in that, if at all possible, sensitive information should
not be stored with the client.  Cookies, for applications that contain
sensitive client information and transactions (on-line banking etc.), should
only contain data that controls the state of the session.  Additionally,
appropriate security controls should be in place with the cookie, i.e.
proper domain, expires at the end of session, marked secure etc.  This
limits the possible exposure of the data to attackers who might compromise
the clients system.

I believe an ideal situation would be to have the information stored in a
secured database controlled by the owner of the server/application.  In this
case no encryption is needed for the cookie.  The user should receive a
unique string (in the form of a cookie) upon authentication with the
application.  The string set in the cookie will act as the session tracking
mechanism for the application, but will be set completely independent of the
user who has just logged in.  The string should then be stored in the
database with the rest of the user's data.  Subsequent requests, by the
client, for his/her data should first verify that the cookie submitted by
the client is the same that is registered with the server.  When the user
logs out, or times out, the string in the database should disappear, forcing
the user to re-authenticate before accessing his/her data again.  It is
important to note that the cookie should be a unique string that cannot be
guessed, i.e. long randomly generated numbers.  This will prevent other
malicious users from hijacking the session.

Greg

-----Original Message-----
From: Mark Curphey [mailto:mark () CURPHEY COM]
Sent: Monday, December 18, 2000 21:54 PM
To: PEN-TEST () SECURITYFOCUS COM
Subject: Re: IE Cookie Crypt-Analysis - Good or Bad


I guess there are several trains of thought but in general (and i'll guess
in classical / traditional terms) I rarely believe you can store anything
securely on a client that you don't (can't control). The client is an
untrusted environment by its very nature. If your ever played with
disassembles for instance, point in case. A good cryptographic
implementation of course would (should) dispel this theory.

I guess it is back to the old adage of how long does the secret need to
remain secret, the concept of crypto periods etc. Of course there will be
better implementations of encrypted cookies than others. Are all cookies
encrypted with the same key for instance, that may open up the possibility
of chosen clear text attacks (you know what your password was, you can get
back an encrypted version) for example. You can't fit that much into 4096
bytes !

Out of interest, what do others use to encrypt cookies. A hash function
would seem on the face of it a good contender, enabling you to get a fixed
length out but I can see situations where it would not do some things I may
want to do with a cookie. Thoughts  ?

-----Original Message-----
From: Penetration Testers [mailto:PEN-TEST () SECURITYFOCUS COM]On Behalf
Of Ruso, Anthony
Sent: Monday, December 18, 2000 1:44 PM
To: PEN-TEST () SECURITYFOCUS COM
Subject: [PEN-TEST] IE Cookie Crypt-Analysis - Good or Bad



Hi All,

        What are common methods used in decrypting/encrypting cookies. Would
many of you trust the use of cookies to store - lets say - passwords and
personal information. I'm trying to extract passwords from a clients website
through the use of cookies. They used to store website passwords in clear
text. I managed to convince them to encrypt them but how can I test their
encryption choice and methods. My crypt-analysis experience is very basic.
Any feedback would be greatly appreciated.

Thanks
*****************************************************************************
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized.

If you are not the intended recipient, any disclosure, copying, distribution
or any action taken or omitted to be taken in reliance on it, is prohibited
and may be unlawful. When addressed to our clients any opinions or advice
contained in this email are subject to the terms and conditions expressed in
the governing KPMG client engagement letter.
*****************************************************************************


Current thread: