I would have sent both to the client. The sequence would be *the* id and is guaranteed to be uinique by the database (or whatever else is around that does this reliably). The idea is that by combining the random secret with the ID and sending the digest with that the ID number can't just be incremented or fooled with. The digest isn't unique but it would keep the unique bit from being fiddled with.
That said, I'm just a paranoid person regarding security (especially for my out-side-of-work work at http://www.greentechnologist.org) and I wouldn't want to keep the random bits around for too long to prevent them from being brute-forced. I'm imagining that someone with a fast computer, the ID number and knowledge of how that combines with randomness for the digest source might be able to locate the bits just by trying a lot of them. I would expire them after a while just to prevent that from happening by stating that if there is a 15 minute session, new random bits are generated each five minutes. New sessions would be tied to the most recent random data. The random data might be expired at the session timeout. This assumes that I'm tracking which random bits are associated with the session to verify that the digest was ok. All that means is that the random-ness is valid as long as the session is still active and normally expires after a time period otherwise. Perhaps other people would get by just keeping a static secret on the server. That may be overkill for many people, it might not be for the apps I'm working with. Joshua b. Jore Domino Developer by day, political by night James G Smith <[EMAIL PROTECTED]> 05/06/2002 01:45 PM Please respond to JGSmith To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: Re: Cheap and unique [EMAIL PROTECTED] wrote: >I've been following this conversation and I'd like to clarify whether my >idea (since I and others want to do this as well) would be use an >incrementing counter for uniqueness. Then also store a bit of secret >randomness, concatenate both values together and create a digest hash. >That hash would be sent along with the sequence as well. This would allow >uniqueness and prevent guessing since the digest would have to match as >well. Depending on my paranoia I could either get fresh random bits each >time (and have a good hardware source for this then) or keep it around for >a bit and throw it away after a period. I think I understand you correctly, but I'm not sure. You mention the sequence being incremented for uniqueness and the digest. I think you propose to send the sequence along with the digest (the digest containing that bit of randomness along with the sequence), but you also mention keeping the random bits around for only a short time, which would indicate they aren't being used to verify the sequence, but produce the sequence via the hash. A digest is not unique, especially with the random bit of data thrown in. For example, MD5 has 128 bits, but can hash any length string. There are more than 2^128 strings that MD5 can take to 128 bits. Therefore, MD5 does not produce a unique value, though it is a reproducable value (the same input string will always produce the same output string). You can replace MD5 with MHX (my hash X) and the number of bits with some other length and the results are still the same -- in other words, no hash will give unique results. The secret string concatenated with the unique number and then hashed can be used to guarantee that the number has not been tampered with, but the secret string would need to be constant to be able to catch tampering. Otherwise, how can you tell if the hash is correct? -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix
