generating a session id

[A. Sinan Unur]

(e-mail address removed) wrote in @c13g2000cwb.googlegroups.com:

http://userpages.umbc.edu/~mabzug1/cs/md5/md5.html

The unofficial MD5 home page has information on collision weakness of
MD5.

Thank you for pointing that out. I am not sure exactly what this means for
the validity of using MD5 for session keys, but it is good to keep in mind.

to ensure a unique value for the session id, it would seem that
querying the database table of session ids to ensure that a new id is
unique prior to entering it in the table would be a good idea.

You are missing the point of session hijacking.

 

[Joe Smith]

for (my $i=0;$i<$length;$i++) {$out .= $array[rand(36)]}

The first method is from Apache:Session:MySQL. Why is it any better
than my version for generating a random 32 character string?

The rand() function does not have an infinite supply of bits.
It will start repeating after a while. A 32-bit algorithm has
a little over 4 billon bit patterns, which does not cover the
full gamut of 9 base-36 characters.

I expect that by the time you get to the 10th character, the
remaining characters of your method are predictable and not random.
-Joe

 

[Joe Smith]

I have made an effort to understand a process by exploring it in its
most basic form, as if I had to create for the first time. Of course
my simple minded code is not as good as the real thing, but why?

When I connect to your server and get a session ID using your algorithm,
with not too much effort I can determine the current seed of your rand()
function. With that knowledge, I could predict what the next session ID
is going to be, and start hijacking your customer's sessions.

Your method has insufficent entropy and is not of cryptographic quality.
-Joe

 

[Henry Law]

The first method is from Apache:Session:MySQL. Why is it any better
than my version for generating a random 32 character string?

Anyone who's seen my posts in this group knows that I'm a comparative
newbie to Perl and wouldn't presume to advise you on that score. But
I'm an oldie at systems architecture and design in general and on
those subjects I will advise.

First question: why _not_ use Apache:Session:MySQL? Your only reason
to date is that you're not using the rest of it. Just because you've
coded "use Apache:Session:MySQL;" doesn't - unless I'm mistaken - mean
that perl is executing any of the stuff you don't use, so why not just
include that whole wonderful module and use the tiny bit that does
_exactly_ what you want?

Second: if there is a coherent answer to the question above, then are
you sure you're making a good trade-off, increased security (which the
Apache module will certainly give you) against whatever-it-is
(performance is what you're worried about, I guess). Performance can
be fixed; are you planning a million transactions an hour or
something?

Lastly: you're wanting the Apache module to be better than your code
before you'll use it. I suggest most strongly that it doesn't need to
be better to be worth using; it needs just to be as good. Something
someone else wrote (and - most importantly - continues to maintain),
that you can get for free, should be your _first_ choice, even if you
could write it as well yourself. (If you have to pay for the code
then there is still an trade-off but it's not as simple).

 

[Henry Law]

'Worthless' is a strong criticism for a
simple piece of code which works

I'll jump in here; Perl I might not be expert in but I've been around
programmers and systems people for long enough to know what asu is
going on about.

Firstly a simple rule, which applies in this group if not in other
places: all code works (absent an error in the perl interpreter). The
difference is between code that does what its author intended it to do
and code that does something unexpected.

Secondly, the worth of code is related to lots of things other than
whether it produces the desired result. The length of time it takes
to write is part of it; the degree to which some maintenance
programmer can make sense of it is a large part (so for throw-away
code the criteria are very different); but there is also an aesthetic
angle to this, understood by all who would be truly excellent at their
craft. (Many project managers and executives don't understand this.)

ASU's point is that your code was a laborious (and therefore
error-prone) way to do something that Perl can do easily and neatly,
so you failed to exploit the resources of the language. Since you're
writing non-throw-away code its worth is therefore very low.

But you must understand that he applies "worthless" to the code, not
to its author.

 

[ioneabu]

My only reason for not wanting to use it is that it requires that
Apache:Session:MySQL requires the use of a hash as follows:

#establish new session
tie %session, "Apache::Session::MySQL",undef,
{
Handle=>$dbh,
LockHandle=>$dbh
}; #just an example of starting a new session

The %session hash is tied to an object of the Apache::Session::MySQL
class which allows the user to store and retrieve session related
persistant data from the MySQL database using the familiar hash as an
interface rather than querying the database directly. In my limited
work with sessions and related persistant data, I feel more comfortable
dealing directly with the database. Maybe the Apache:Session way is
more portable. Since I do not use the %session hash for anything other
than to access the produced session ID or to validate if an existing ID
is valid, I found myself passing around %session almost as a dummy
variable. I decided to experiment with creating the session ID myself
for these reasons. Admittedly, my method was inferior to the way the
Apache:Session module does it. To be honest, a big weak point in my
programming skills in any language is studying other people's code. I
wrongly thought that it would be more instructive and fun to write my
own session ID generator based on Perl's random number generator. My
original posted code was admittedly poor by Perl standards and as I
previously stated, I wish I had thought of the right way myself. I
should read all basic material on dealing with arrays and hashes over
and over until it sinks in. When I finally took the little bit of time
and effort it took to look into the workings of Apache:Session and see
the MD5 way they do it, I wrongly thought that my way was just as good
because who will ever know how I am generating my ID's anyway? The
correct solution in my case was to use the one-line statement from
Apache:Session for creating the ID in my own sub and be done with it.
I don't feel I was stupid or wrong to ask why to use one method over
the other and I feel that I stated that question appropriately by
placing both methods side by side in a simple piece of self-contained,
runnable code. Joe Smith provided a very nice rigorous explanation for
why my simple minded solution was wrong. There is probably more to it
than that, but why go any further at this point? It's like me going to
the store to buy a steel, fire-proof safe and then deciding to build my
own version out of wood. Rather than arguing with the salesman over
the benefits of his tested and proven safe over my home-made solution,
I should just buy the real thing and move on with my life without too
much further probing. The wood project may be a fun, useful diversion
in my own free time, but if I need a strong, secure fireproof safe, I
should check with consumer reports, buy the best one, and use my free
time to figure out what to put in it.

Thanks for all help!

wana

 

[A. Sinan Unur]

(e-mail address removed) wrote in @f14g2000cwb.googlegroups.com:

It's like me going to the store to buy a steel, fire-proof safe and
then deciding to build my own version out of wood. Rather than arguing
with the salesman over the benefits of his tested and proven safe over
my home-made solution, I should just buy the real thing and move on
with my life without too much further probing. The wood project may be
a fun, useful diversion in my own free time, but if I need a strong,
secure fireproof safe, I should check with consumer reports, buy the
best one, and use my free time to figure out what to put in it.

A genuine thank you for this post. I am sure it will be helpful to others
who might be going through a similar thought process to read this succint
and clear explanation.

Sinan.