[EMAIL PROTECTED] wrote: >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.
Thanks for the clarification -- makes a lot more sense. At first glance, I think that would work. -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix
