Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security SecProg
[Top] [All Lists]

Re: ASP/ASP.NET Session IDs

Subject: Re: ASP/ASP.NET Session IDs
Date: Thu, 17 Mar 2005 15:41:24 -0800
On Thu, 17 Mar 2005 18:35:02 -0500, Darren Bounds
<dbounds@intrusense.com> wrote:
Based on your question it sounds like you're missing an important step
in the process. The 16-byte cookie string is not merely an encrypted
32-bit unsigned integer, but rather the 32-bits combined with X bits of
random data. Exactly how much data I'm not sure.

Right, but depending on how this random data is generated (ie, how
random is random), this may not be terribly usefully random data (TCP
sequence nubers in some implementations, for example).

Additionally, if it were possible to 'guess' the session ID in any sort
of repeatable fashion other than brute forcing, that would represent a
very flawed and unusable cryptographic algorithm.

Certainly, but that would be the point of looking into it.  I mean,
MD5 was thought to be a great hashing function, but an exploit has
been found.  I was wondering what they were using for encryption, and
if it might be similarly vulnerable.

-- 
Steven DeFord
steve@singingtree.com
(925) 596-0426

<Prev in Thread] Current Thread [Next in Thread>