Is md5(data + key) secure if a proper hmac function isn't available?

Question

I need to generate a MAC signature for data on a website, but it's in a HTML templating system where there's only a few functions available. The only hashing function available is md5. Ideally, I'd use a real hmac function, but since that's not an option here, is it secure to have something like the below?

secret_key = '...';
data = '{"user_id": 123, "timestamp": 12345}';
signature = md5(data + secret_key);

I know that hmac-md5 is considered secure, and I know length extension attacks are possible if you use the construction md5(secret_key + data), but is the reverse, md5(data + secret_key) also insecure? It seems like it shouldn't be vulnerable to length extension since the key gets added to the end. Or is this not an issue anyway for the case where data is a JSON string like above, since you can't add characters on to the end of a valid JSON string and have it still be valid?

The specific use-case is that I have a CMS that I'm theming using liquid templates, and the template needs to make requests to a API that I control. I need to know who the user is that's making the request, and verify that they are in fact logged-in on the CMS when the request arrives at my API. My solution is to use the above md5 signature system to sign some info about the user in the Liquid template compilation, and then on my API server I can verify that signature since the secret key is shared between both my API server and the liquid template, so I know the data hasn't been tampered with. The CMS I'm using is a hosted cloud service and provides no other way to verify the identify of the logged-in user thats available to javascript running on the page (at least that I know of).

Answer 1

No, md5(data+key) is not secure. MD5 is vulnerable to dirt cheap collision attacks. It's possible to craft a data1 that is innocuous and that your system, or the code that's calling your system, accepts as valid, and then later submit data2 which is malicious but such that md5(data1+key) = md5(data2+key), without knowing key (the collision works for an arbitrary suffix).

md5(key+data) would be more secure in this respect, because generating collisions would require knowing the key. However, it has other weaknesses, in particular a length extension attack which allows finding a specific md5(key+data2) from md5(key+data1). While the attack doesn't allow any freedom on the content of data2 given data1, sometimes all it takes is to arrange for an admin bit to be 1 instead of 0, and all it might take is a few tries of different data1 until the corresponding data2 works for the attacker.

The good news is that if you have a hash, you do have the corresponding HMAC. HMAC is a simple construction that just requires two applications of the hash function. In JavaScript-like pseudocode (I think this is valid code if xor is a function that performs xor on byte strings and pads key with null bytes if it's shorter, but I'm not competent in JavaScript and it's possible that string encodings make this a bit more difficult):

function hmac_md5(key, data) {
  return md5(xor(key, '\x5c'.repeat(32)) +
             md5(xor(key, '\x36'.repeat(32)) +
                 data));
}

If expressing xor is really impossible, my recommendation would be to keep the important parts of HMAC, but avoid the known pitfalls (collisions, length extension, algebraic relations). You'd end up with a construction that hasn't been studied, but at least you can avoid known weakness within your constraints. The following construct keeps the gist of HMAC, which is to do hash(key+_) with two different keys (here with a constant prefix to ensure that the two hash invocations don't start with a common prefix). It's homemade and hasn't been studied, so it isn't great, but it's better than using a construct which has been studied and broken.

function homemade_mac(key, data) {
  return md5('a' + key +
             md5('bc' + key +
                 data));
}

Using HMAC-MD5, or even worse a homemade construct, is not ideal, and you should arrange to upgrade your system to support an unbroken hash (SHA-2 or SHA-3), if only because it's a sign that other parts of the system are probably using MD5 in a vulnerable way. But HMAC-MD5 does not have any known vulnerability (other than being a bit too short at 16 bytes, but that at most leads to very expensive attacks which only become plausible if you have billions of data objects in your system).