From: Ng Pheng Siong <[EMAIL PROTECTED]> > A URL concocted by my app looks like this: > https://whatever/object?action=something&expiry=timeval&cap=XXYYZZ > The "cap" at the end is supposed to be a capability. ;-)
> cap = hmac-sha1(key, "/object?action=something&expiry=timeval") > 1. Is the construction of the "cap" string ok? Should I stir other > info in? (The expiry timeval provides the temporal information.) You haven't stated what it's for although it looks as if you want to ensure the user who ran one stage of an app is the same as in a later stage. In particular you haven't said whether the page should be accessed multiple times during the validity period. You haven't included a start time to the validity period or stated anything about secure time at the server(s). If this was a website where the user might want to share an URL with outsiders and you might want to prevent deep linking (by technical means; by far the best way if you care at all) you might want to include something of the browser properties. > 2. The key is created from /dev/random. How long should it be? In my > threat model, the key changes every few hours. /dev/urandom might prove more reliable. The length should be enough to prevent brute force key discovery by users who have all the other URL data. I see no reason to stint on the length - 100 bits should be plenty. Does the old key need to remain in use for a period or are you planning for rejections at changeover time to be retried ? > 3. Any other thoughts? Aren't GET-style URL parameters prone to get logged in proxies and is that what you want ? POST is usually advised to avoid this. This crypto-cookie idea sounds roughly equivalent to an opaque key to a lookup table on the server. In that case round-robin webservers might be a bit trickier but it should buy you shorter URLs. Can mod_rewrite help at all ? I'm not very familiar with it. What are you planning to do when the CAP is invalid ? Divert to honeypot ? --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
