And leaving this specific example aside for a moment, I was trying to prove a larger point: people write crypto code for a reason. Some people will write it for no reason at all, yes. A lot of other devs will be dying to save themselves the time it will take to write any type of code, especially if it has to deal with something they aren't experts in, but they just can't. Now, it seems likely you and I can hash out the details of an acceptable solution in this discussion (in fact, I think once you take the steps to make sure the random source isn't predictable, you're good, but even this is slightly crypto-related), but how would the average developer know this? How would he go from "don't write crypto code" to this? In my humble opinion, simply saying "don't write crypto code" isn't a solution, and there are good reasons why this hasn't worked so far.
Here's a principle from which you could derive "use unique tokens to identify the user": effectively, TLS already has a mechanism of fingerprinting users, called "client certificates." Their current browser UI sucks (much like HTTP Basic Auth) so nobody uses them (much like HTTP Basic Auth), and instead provides poor reimplementations of them (much like HTTP Basic Auth.) If you think about what you need to simulate having a client cert--a persistable shared secret generated by the host and securely sent to the client--then "a long random key inside a cookie" is what you'll be naturally lead to.
Usually this sort of code is already present and well tested in whatever web framework you're using and there's just no good reason to write it again yourself. Best case is you wasted your time, worst case it's buggy and insecure.
And leaving this specific example aside for a moment, I was trying to prove a larger point: people write crypto code for a reason. Some people will write it for no reason at all, yes. A lot of other devs will be dying to save themselves the time it will take to write any type of code, especially if it has to deal with something they aren't experts in, but they just can't. Now, it seems likely you and I can hash out the details of an acceptable solution in this discussion (in fact, I think once you take the steps to make sure the random source isn't predictable, you're good, but even this is slightly crypto-related), but how would the average developer know this? How would he go from "don't write crypto code" to this? In my humble opinion, simply saying "don't write crypto code" isn't a solution, and there are good reasons why this hasn't worked so far.