5
Which algorithm used to secure a single session_id()? I wanted to know what the creation and verification is like to ensure that such an ID does not collide with an existing one?
I need to create some hashes, but I’m afraid that an hour or two or more entries might create the same hash.
2
I usually use the user’s IP ($_SERVER["REMOTE_ADDR"]) with timestamp in seconds from the time of creating the session using the function team() along with some keyword, all this convert to md5 (md5()) or sha1 (sha1()) and create my hash!
For an even more precise one, you can use the function microtime() that returns time in microseconds, which makes it more difficult (perhaps impossible) to have an equal hash, mainly concatenating with ip.
I hope it helps.
Hugs
2
To see how the identifier is generated, it is enough look at the code, basically it is based on MD5 by default, but can be SHA1 or another.
Other ingredients:
My PHPSESSID generates a string of 26, and using MD5 generates a string of 32. It is created based on MD5 should not keep the string length?
@Interesting Papacharlie. According to this reply of the OS, this feature will depend on the session handler used, and second that thread of sitepoint, the length is of 32 characters in PHP 5.2, already in the 5.3, is of 26. I’m looking for more to know if this is true. =)
Here is 5.4.28 and I didn’t change any of Seth’s confession. Hypothetically; a system is mounted waiting for a HASH-based SESSIONID with a length of 32, and when it goes to run it is only 26. PHP always surprising.
2
The default PHP behavior is to use the hash md5 or sha1 of some values obtained at the time of ID generation:
/dev/urandom).Is it possible to have a collision? Yes! As it is known, both MD5 and SHA1 are unsafe. But the goal is simply to make computationally expensive brute force attacks. So much so that in the case of PHP, there is no collision treatment.
In the case of implementing a data structure that aims to quickly search for values (such as Hash Table), this is not the best way. One should consider only the data itself in Hash. Otherwise, you will not be able to recover your data.
The implementation of collision treatment is mandatory in most cases, and it is up to you to decide which of the implementations to use. The collision treatment algorithm may or may not be suitable according to the nature of the operations to be carried out.
Possible Collision Handling in PHP
In the case of PHP, I believe that simply generating a new hash again is enough. This works because even though the client’s IP is still the same, the random number for sure (well... hopefully, right?) will change, and the time will probably change too. Then I see no reason to repeat the procedure until a collision does not occur.
I am not going to discuss the collision in the case of data because I believe it is not the domain of questioning.
I didn’t know that PHP didn’t treat collision. The problem is having a UNIQUE field and at some point colliding the HASH. What would be the 'treatment' for the case?
I edited the answer.
When you say "PHP does not treat this collision" you refer to the manipulation of the sesssions?
Exactly. If PHP generates two equal session Ids, it will not know, and the session will be shared by the two clients. This can create problems of all kinds depending on your application (let’s say this is hell for banking and e-commerce applications).
Do you have a reading reference? This is the type of catastrophic failure.
Looking for "php Session Collision" on Goole, here are some results. Other than that, it’s happened to me in one of my clients. The damage was small (crash of a third-party CGI application), and I found out only because we kept an extensive log of access. After that, I studied the source code, at the time of version 4.X, and today I checked in version 5 if there is still the problem. These are my only references. If you discover anything else, please share =]
Browser other questions tagged php session hash single-restriction
You are not signed in. Login or sign up in order to post.
Actually I have a numerical sequence based on TS along with 10 random numbers, but using md5 ends up creating the possibility of collision. That’s why I wanted to know
SESSION. But thanks for the answer.– Papa Charlie
@Papacharlie Accidental MD5 collisions are very unlikely (while collisions intentional, i.e. malicious, are relatively simple to produce), since it is clear that the hashed data are distinct (this is the difficult part).
– mgibsonbr
@mgibsonbr Murphy’s Law... very unlikely means it will happen (rs). If there is collision I will not be able to get around the problem...
– Papa Charlie
A random UUID has 122 bits (<16 bytes, half of an MD5). If you generate a few tens of trillion of these in a year, the chance of a collision is roughly the same as if you were hit by a meteorite in that same period... I’m not going to guess anymore, because I don’t have enough knowledge to say anything safely, but in general I say that the distinct data hashes will also be distinct, even for a "broken" algorithm like MD5 (again, unless this collision was purposefully made).
– mgibsonbr