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: ip=xxx.xxx.xxx.xxx×tamp=yyyy-mm-dd&seq_num=13 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 string. or: 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. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
