I'm reviewing API documentation from a potential supplier.

In order to gain access to the useful parts of the API, we have to send a GET or POST request to a particular endpoint passing two parameters - our organization name and the "public key hash". This endpoint will then return a token that we use for the remainder of our session.

The description of the "public key hash" is that we take a public key (provided in advance to us by the supplier), append the current UTC date and then perform an MD5 hash of the result. Their example is:

Public Key: a8db14aef3810a92e7c9af9f8782e1f0
Current UTC Date: 2013-02-28
Result string: a8db14aef3810a92e7c9af9f8782e1f02013-02-28
MD5 hash: efdb500ca0a4e107aea100554456ea85

I've not encountered an authentication mechanism like this before. It feels "hand-rolled" to me, and the use of MD5 is also setting my nose hairs twitching - do I really want to be writing new code in 2017 that uses MD5?

But before I really dig into things - is this actually a well-known and used authentication mechanism that I've just failed to find any documentation for? If so, is it actually still considered to be safe?

(Searching on the API key value in the example produces no results, so they've at least rolled a unique example for some reason. Searching on API authentication md5 didn't find any promising results either)

  • 1
    I am not at leisure to dig into it enough to provide a good answer, but on reading your question, I would share your concerns. It sounds like they intend for you to keep a public key private, which in the content of authentication would make me a bit wary about other aspects of their solution Mar 7, 2017 at 14:33
  • I am sharing your concern. Although this particular use-case doesn't require high levels of security as far as I can tell, those shady practices are a good tell that something even worse happens behind the scenes. Since you don't provide the actual API there is no way of knowing, but the gut feeling is that this is something to avoid.
    – MiaoHatola
    Mar 7, 2017 at 16:41
  • The protocol looks like a bastardized version of Kerberos/OAuth protocol. Authentication method itself has its own issue 1. Passing Public key instead of using it for encryption seems weird. 2. Any hashing approach should have some sort of nonce to avoid replay attacks.
    – jhash
    Mar 8, 2017 at 23:25

1 Answer 1


EDIT - This is probably based on DIGEST-MD5 or similar - Wikipedia currently claims it's still secure, but there's a "citation needed" in a crucial place. Using MD5 is generally a bad idea.

The intention of the hash step is to protect against accidental leaking of the token/password. By hashing with the time, you're basically deriving a shorter-lived token and sending that instead of the original one, so if the derived token were leaked, the original one would still be safe (assuming the security of MD5, so...).

Over HTTPS, this scheme doesn't really offer much more protection than an OAuth Bearer token. It isn't any worse than an OAuth Bearer token of equivalent length, but the fact they've used this scheme (as well calling their secret token a "public key") makes it reasonable to assume that they're not that hot on security, and that will probably be reflected elsewhere in their business (e.g. securely storing the data you send them).

If you're sending this over plain HTTP, then it is better than just using the actual token - but you have other problems, because you need HTTPS to prevent MITM (because a bearer token doesn't help).

  • If the hash covered more than just the time, but instead the message contents itself, then it would be a bad version of the lesser-used OAuth MAC.
    – cloudfeet
    Mar 7, 2017 at 17:04
  • Yes, HTTPS. But as you may notice in the example, the derivation uses the date, but no time. So, 24 hour window. Does that count as "short-lived"? :-) Mar 7, 2017 at 17:33
  • Good point - changed it to "shorter-lived". :)
    – cloudfeet
    Mar 7, 2017 at 17:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .