4 ms·

The cookie should consist of the user's username, followed by a separator character, followed by some large random number Why not just use a random number on i

The cookie should consist of the user's username, followed by a separator character, followed by some large random number Why not just use a random number on its own? There's no reason I can see to bother with the username.

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 ago
  The 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 ago
  Unless 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?
tptacek 16y ago
There is no reason to bother with a username if you have a suitably large random number.

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 ago
The 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 ago
Unless 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?

tptacek 16y ago

There is no reason to bother with a username if you have a suitably large random number.