URL Signing with HMAC or OpenSSL

问题:

I'm interested in url signing (e.g. http://.../?somearg=value&anotherarg=anothervalue&sig=aSKS9F3KL5xc), but I have a few requirements which have left me without a solution yet.

• I'll be using either PHP or Python for pages, so I'll need to be able to sign and verify a signature using one of the two.
• My plan was to use a priv/pub key scheme to sign some data, and be able to verify that the signature is valid, but here's where it gets complicated:
• The data is not known when the verification is happening (it is not just somearg=value&anotherarg=anothervalue)

My first instinct was to use OpenSSL, e.g. with a RSA keypair, to do something along the lines of signing by: openssl rsautl -sign -inkey private.pem -in sensitive -out privsigned and verifying based on the privsigned data and key ONLY: openssl rsautl -verify -inkey public.pem -in privsigned -pubin.

Using PHP's openssl_get_privatekey() and openssl_sign() signs the data just fine, but I need to know the (decrypted!) data in order to verify (which I will not have): openssl_get_publickey() and openssl_verify($data, $signature, $pubkeyid); from http://php.net/openssl_verify.

Or am I missing something here?

---

So I looked into HMAC, but although many hash function are available in both Python and PHP, I'm baffled as to how I'd go about verifying the hash. PHP's hash_hmac() allows me to create a hash using a "key" (or in this case a string-key). But how do I go about verifying that a hash is valid (i.e. &sig= hasn't just been manually put in by the end user &sig=abcdefg1234.

So to sum up (sorry for the long question): How can I verify that a signature/hash has been made by my server's (cert/string)key (given I can not verify by redoing the hash of said data)? And do you have any preferences as to which route I should chose, Priv/pub-key or HMAC?

Any pointers big or small is greatly appreciated! Thanks in advance,

• Josh

回答1:

HMAC is a symmetric algorithm, so there is no separate creation and checking algorithm. To check, you simply compute the hash as it should have been computed originally, and check that the result equals what you actually got from the client. The security rests on the HMAC key only existing on your server.

Unless you need the signatures to be verifiable by someone who doesn't know the secret key, HMAC is probably a better choice than public-key systems, for reasons of efficiency. It can take several milliseconds to create or verify a public-key signature (some years ago I timed one implementation at 15 ms per operation), whereas HMAC is quite fast.

(Oh, and you cannot verify any kind of signature without knowing the data it's supposed to sign. That wouldn't make any sense, as far as I can see).

回答2:

As Henning Makholm pointed out, HMAC is a better choice than public key. There are some best practices you should consider for your particular scenario that will impact your choices:

• Do you want to consider the hostname and scheme (http/https) in the signature? Maybe.
• Do you want to consider the path in the signature? Probably.
• Do you want to consider the query string in the signature? Probably.
• Do you want to normalize the argument order and escaping prior to signing? Usually not.
• Do you want to embed signature time etc (to create time-limited URLs)?
• Do you want to tie the signed URL to some other user state, such as cookie?
• Are you using user-generated or user-visible content directly in the HMAC? If so, you should "salt" the key using a value that is randomized for each request.

When computing the signature, you'll need to encode it in a URL-friendly way (base64 and base32 are popular choices) and choose an HMAC algorithm (such as SHA-256), and decide how many bits of the signature you want to keep (truncating the HMAC value in half is usually safe). If you choose base64, beware of the different alphabets used by url-safe vs non-url-safe implementations.

Here is a pseudocode implementation (w/o error checking or salting etc) for signing path + query string:

const secret = ...;

def sign(path, querystring):
  return path + "?" + querystring + "&sig=" + url_encode(base64_encode(hmacsha256(secret, path + "?" + querystring).truncate(16)))

def verify(path, querystring):
  querystring_without_sig = remove_query_parameter(querystring, "sig")
  sig = base64_decode(url_decode(get_query_parameter(querystring, "sig")))
  if hmacsha256(secret, path + "?" + querystring_without_sig)[:16] != sig:
    raise "invalid sig"

HMAC SHA256 is recommended and is available in all common languages.

Java:

Mac mac = Mac.getInstance("HmacSHA256");
mac.init(secret);
return mac.doFinal(value.getBytes());

Python:

hmac.new(secret, input, hashlib.sha256).digest()

PHP:

hash_hmac("sha256", value, secret);

回答3:

If you want to use HMAC and Python, then:

$ pip install ska

On the client side

from ska import sign_url

signed_url = sign_url(
    auth_user='user', 
    secret_key='your-secret_key', 
    url='http://e.com/api/'
)

Produced URL looks like as follows.

http://e.com/api/?valid_until=1378045287.0&auth_user=user&signature=YlZpLFsjUKBalL4x5trhkeEgqE8%3D

On the server side

Note, that in example below request.GET is given as example. It will most likely vary from what's used in your framework (unless you use Django).

from ska import validate_signed_request_data

validation_result = validate_signed_request_data(
    data = request.GET, # Note, that ``request.GET`` is given as example.
    secret_key = 'your-secret_key'
)

The validate_signed_request_data produces a SignatureValidationResult object, which basically holds two properties:

• result (bool): True if data is valid. False otherwise.
• reason (list): List of strings, indicating validation errors.