Finding the common thread...

[christopher.riley at r-it.at (christopher.riley at r-it.at)]

As part of some research I'm doing I've started looking at the method used
to create session keys within a custom coded program. As I don't have
access to the source-code (and never likely will) I've been doing my best
to figure out the process from the information I have to hand.

Due to the fact that the session ID's created can never repeat (all
sessions are logged to a SQL database using the session ID as the Primary
Key, duplicates therefore cause a database error) it seems very possible
that the session ID's are created based on a mathematical formular using
the timestamp as input. By mixing multiple inputs (such as
username/password/system name etc...) the program runs the risk of creating
a SessionID that already exists.

This is were my problem starts. In order to prove the theory, I need to
find how the timestamp is manipulated to create the SessionID. I have
access to the logfile containing 35,000+ valid sessionID's and the
timestamp of the logon. Given these two linked piece of information, what
can be done (in a automated or semi-automated fashion) to find any common
threads between these values ?

Additional Info .:

The timestamp is a standard unix timestamp. The web-application is C based
(CGI), and the resulting SessionID's vary between 5 and 10 characters in
length (there is no visual pattern between the length and the timestamp).

Any ideas ?

Chris
----------------------------------------
Raiffeisen Informatik GmbH, Firmenbuchnr. 88239p, Handelsgericht Wien, DVR
0486809, UID ATU 16351908

Der Austausch von Nachrichten mit oben angefuehrtem Absender via E-Mail
dient ausschliesslich Informationszwecken. Rechtsgeschaeftliche
Erklaerungen duerfen ueber dieses Medium nicht ausgetauscht werden.
Correspondence with above mentioned sender via e-mail is only for
information purposes. This medium may not be used for exchange of
legally-binding communications.
----------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pauldotcom.com/pipermail/pauldotcom/attachments/20090615/f1d8a34f/attachment.htm