Constructing "capability" URLs

[lists at notatla.demon.co.uk]

From: Ng Pheng Siong <ngps at netmemetic.com>

> 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 majordomo at wasabisystems.com