Re: Safe session IDs

From: Hector Herrera (
Date: 01/11/02

Date: Thu, 10 Jan 2002 15:54:17 -0800
To: "Ryan M Harris" <>, <>
From: Hector Herrera <>

At 12:38 PM 10/01/02 -0500, Ryan M Harris wrote:
>What is the most secure way of generating a session number?
>I have used the following formula in the past. Is it secure (from a
>randomness perspective)? Any way to make it more secure/random?
>sessionid = md5( <REMOTE_IP> + REMOTE_USER_AGENT> + rand() (5 bytes from
>here) + microtime() )
>Ryan M Harris

Before I start, you should read chapter 17.14 "Real
Random-Sequence Generators" in "Applied Cryptography"
by Bruce Schneier.

My first piece of advice is to use the actual number of
random bits that you really need. Do you really need
128 bits of randomness? Won't your web server be able
to notice that something strange is going on if you are
getting 2^64 number of requests, each of them with a
different sessionid, but they are all coming from the
same source IP??? Even 2^8 requests from the same IP
should set off alarms.

The first thing that you need to do is implement a
method for detecting brute force attacks and to stop
them before a large chunk of your sessionid keyspace
is searched.

Second thing that I am going to say, is that the
REMOTE_IP and REMOTE_USER_AGENT are completely under
the control of the end user, that means that those
variables do not add to the randomness of the sessionid.
Take them out.

If you truly wanted random numbers, I would recommend
that you purchase a dedicated computer with an intel
810 or newer chipset that has an 82802 firmware hub
device. That device has a built-in hardware random
number generator. Here is the URL for more info:

and a search on google returned quite a few different
solutions with a wide range of price ranges, there is
even a home made kit that can be made from $40 worth
of parts ... here is the link to the google search:

I hope this helps.


Relevant Pages

  • Re: Concurrent access to /dev/urandom
    ... >has more randomness available. ... /dev/urandom uses a cryptographically secure PRNG, ... pseudorandom output as you like without worries (unless someone breaks ... the crypto, ...
  • Re: implementation of one-time-pad with Mersenne Twister PRNG
    ... Such a stream cipher is secure if the pseudo-random ... No it does NOT have ALL the statistical properties of "true" randomness. ... Soviet OTP ... It seems to me that the distinction between a stream cipher and a OTP ...
  • Re: Java encryption implementation
    ... Yes, Java has 64 bit longs, I could build an extention for 256bit longs ... I'm pretty clear about the fact that it only creates pseudo-randoms, ... you think though that more _randomness_ is important to make it secure? ...