3 ms·
If you use a random number by itself, then you have to worry about possible collisions. When the cookie does not contain the username, you, the server, need to
by mkenyon 16y ago
If you use a random number by itself, then you have to worry about possible collisions. When the cookie does not contain the username, you, the server, need to look up in your table to whom you gave the random number. This works, but in this case the attacker must create a random number and hope it collides with an existing one (even for significantly large fields).
However, if the cookie consists of a username and a random number, the previous strategy is no longer feasible. The Cartesian product of usernames and random numbers from a large field is too great a set to consider attacking. An attacker's only hope in this implementation would be sniffing or MitM attacks (which I should add are much scarier than brute force attacks).
- jerf 16y agoThe probability of collisions with 128 truly random bits is less than the probability of your CPU incorrectly executing a given opcode. And by that I don't mean an unanticipated logic error, I mean literally that your CPU is instructed to add 2 and 3 and gets 1029. Once you push the odds of some event below the noise threshold of CPU error, it ceases mattering, because you've pushed past the point where you can't do anything about it anyhow anymore. CPUs are very reliable but their failure probability is not 0.
- Sidnicious 16y agoUnless I'm mistaken, isn't this just adding a few more bits of randomness to your random number? > When the cookie does not contain the username, you, the server, need to look up in your table to whom you gave the random number. When the cookie does contain the username, I have to look up whether that random number is valid for the given username. How is that better?