4

Mashery allows authentication via digital signature as follows:

  • First, concatenate the following components:
    • API key
    • Shared secret
    • UNIX Timestamp
  • Then, create an MD5 hash of the concatentated string.

The documentation states that the unix timestamp only needs an accuracy of +/- 5 minutes. Details: http://support.mashery.com/docs/read/mashery_api/20/Authentication .

Assuming this is not a trade-secret, what is the algorithm for performing authentication like this?

Specifically, how is it possible when the unix timestamp can vary by 5 minutes? A "brute-force" technique might be to calculate a signature for every possible timestamp value until finding a match (or not), but that doesn't seem practical for authenticating frequent API calls.

Peter O.
  • 32,158
  • 14
  • 82
  • 96
kaliatech
  • 17,579
  • 5
  • 72
  • 84

4 Answers4

3

Yes, that appears to be what it does. The documentation link you gave states, " A five-minute wiggle is permitted on either side of the current timestamp on the Mashery server to allow for reasonable clock drift." That means they need to check up to 600 hashes to see if the submitted one is valid. 5 minutes is 300 seconds. Plus or minus makes it 600 checks.

It seems practical to me. 600 MD5s is not a lot of processing to do. In fact, a modern password validator (like something that uses bcrypt) would perform much more work to validate a password.

Fantius
  • 3,806
  • 5
  • 32
  • 49
  • I suppose you are correct. In my mind, I was mistakenly thinking in interval terms of milliseconds, not seconds. A smart implementation would probably also start at offset zero and go up and down just until finding a match (and so rarely ever requiring the full 600 checks.) Bounty will be awarded assuming no one else comes along with an efficient technique for doing "partial" MD5 hash matches when given two components of three used to generate the hash. (...which AFAIK, is not possible.) – kaliatech Nov 10 '11 at 16:32
  • Thanks. Also Mashery could have reduced the amount of work required by a factor of 60 by measuring time in minutes instead of seconds. They chose the far more common seconds-since-epoch measurement over minutes-since-epoch. – Fantius Nov 10 '11 at 17:46
  • 1
    Furthermore, they could have said: take the seconds-since-epoch and divide it by 600. Then they would only need to perform a single hash. – Fantius Nov 10 '11 at 17:48
  • Thanks @Fantius you helped me a lot with that last comment! That's what I ended up using, dividing by 600 works great if you don't need extreme security. – Patrick Murphy Oct 28 '15 at 18:34
2

Amazon give a good example of request signing and in quite alot detail which should make the mechanics obvious (I realise its not mashery - but i think it's what your after, or will at least help on your journey to API security happiness)

http://docs.amazonwebservices.com/AmazonS3/latest/dev/index.html?RESTAuthentication.html

James Butler
  • 3,852
  • 1
  • 26
  • 38
  • That's really interesting info. Thanks. However, looking through the details I don't think this answers my question. Specifically, it seems AWS expects the timestamp to also be provided unhashed via an HTTP header. So obviously they can compute the exact signature hash without dealing with system time differences. In the case of Mashery, the date is not passed outside of the hash. – kaliatech Nov 16 '11 at 14:42
  • The AWS method seems easier for the server (less computation needed), and doesn't make the clients work any harder and doesn't reduce security in any real way (unless you have some weird niche security considerations). Sure you could change the visible timestamp in the query string but then the signature wouldn't match. – James Butler Nov 16 '11 at 16:31
  • I completely agree. The AWS method seems better at 1st glance to me as well. I asked the original question out of curiosity to see if there was maybe something I didn't understand about MD5 hash digital signatures. I don't intend to replicate the Mashery approach. – kaliatech Nov 16 '11 at 21:42
0

Mashery could also pre-generate the list of valid signatures or cache each sig on demand. The signature is global to all API's that Mashery is protecting for that API Key / Shared Secret, so there is no need to validate the API call uniquely for every request.

EJ Campbell
  • 685
  • 5
  • 4
0

sha256 is pretty fast. Even in php, you can calculate 830K sha256's a second, so they very likely just brute force it.

<?php

$COUNT = 6000000;
$start = microtime(true);
for($i = 0; $i < $COUNT; $i++) {
  $out = hash('sha256', 'wefjklwfekjlewfjklwefjklfwejkwefjklwfekjl' . $i);
  //print("$out\n");
}
$total = microtime(true) - $start;
print("Time: $total\n");
print("sha256's per second: " . ($COUNT / $total) . "\n");

?>
EJ Campbell
  • 685
  • 5
  • 4