Alberto Serra wrote:

> So you mean I have a 32 byte MD5 session id to identify the current 
> visit, plus another such thing to identify the step within it, right?
> But why decrypting it? A presentation attack would give it back to 
> server in the encrypted form anyway. What do we lose by just 
> generating a random MD5 key and using it as it is with no encrypted 
> meaning? 

I probably didn't explain this well enough; I was in a hurry earlier. :)

People who use this method of including an encrypted string (I've only 
used it on maybe two sites, because it does incur a performance hit) are 
*adding* to whatever security methods they are already using. So, in the 
case of using PHP's regular session management and adding the IP 
address, sequence number, and timestamp as an encrypted string, you get 
these two pieces of data residing with the client:

1. PHPSESSID in a cookie
2. Really long encrypted string in a cookie, in every URL, or whatever.

Item #2 is generated again on each page. It could be something like this 
when decrypted:

The idea is to make it very difficult to successfully pull off a 
presentation attack. If someone intercepts the encrypted string (which 
you should basically assume is going to happen), it's not going to do 
them any good unless they can achieve the following:

1. Make their IP address appear as close to the real user's IP address 
as necessary, depending on the type of checking you're doing
2. Make sure they request the next page before the real user does, so 
that the sequence number is correct
3. Do all of this within whatever window of time you allow as a maximum 
before the session times out, based on the timestamp in the encrypted 


1. Decrypt the string

Decryption can take a lot of time, depending on the algorithm you 
choose. Additionally, if you make sure the sequence number is exactly 
what you're expecting (rather than just making sure it hasn't already 
been passed), prompting for a password otherwise, you make it difficult 
for the attacker to choose the right one.

Either way, if you can make them attempt the decryption rather than any 
of the other methods, you've done a pretty good job tightening 
everything up. Most people aren't going to go through the hassle of that.

> Now, just tell me if I got you right. Since we are comparing 3 IP 
> octets plus the two MD5 keys we get an attack window like this:
> hacker has three matching octets on his IP, plus he does attack while 
> the real user is still using the visit-session/content-session key the 
> hacker has stolen, right? This makes it dangerous for last pages 
> (those seen right before exiting site), as they actually last for ages. 

This is where the maximum window comes in. You should have a maximum 
window that you tolerate for the users. You'll want to balance usability 
with security here; don't annoy your users too much. :)

Having the sequence number just adds the ability to make this window of 
time much smaller, as most users will browse through a site much more 
quickly than most timeouts. Though the "last page" opportunity you speak 
of does exist, the attacker must guess the correct transaction as well 
as accomplish the feat within your maximum window.

These are just some ideas, mind you. Many people (you sound like such a 
person) can develop their applications quite securely once they can step 
back and see the big picture and follow a few general guidelines, such 
as not trusting data from the client. In this case, the data from the 
client is like a driver's license, and rather than just use the license 
number, we're also checking their photograph and other personal 
information, so that an imposter has a more difficult time. :)

Happy hacking.


PHP General Mailing List (
To unsubscribe, visit:

Reply via email to