2

I've been thinking lately about how all of the authentication methods used in API to API communications (RESTful API's) are mostly methods that have been designed to be human oriented first (tokens\passwords\etc) & how in API this often means you need a secret store to have the passwords\tokens stored in it.

My idea is that the requester API will contact the receiver API with a hashed token & a callback webhook address, the callback URL effectively acting as the user identity which the receiver API then contacts (in a new connection) which he then get the unhashed token from, the receiver token then compares the hashed and unhashed version of the token and should they match he knows that the requester of the original request is in fact the API of the webhook.

A workflow of the auth process is described in full in the following diagram: auth workflow process

I've also created a docker-compose POC of the concept at my github which works as i thought it will (please note that while I will gladly receive notes about the POC this question is only about the theory of the concept as a whole being secure).

The question

Is this really secure? Is there any vulnerability I missed to this authentication method which will allow an attacker to trick the receiver API by impersonating another API?

If there isn't is there any way to prove without a doubt (mathematically or otherwise) that this is in fact secure?

Assume the following are given:

  • HTTPS is used (to protect against MITM) on all requests
  • The backend DB is secure
  • Tokens are generated randomly & are not reused
  • The hashing function is modern enough to provide good protection
  • The DNS register of both API's is secure
  • This is an authentication only method, not authorization nor encryption.
  • The main risk that this tries to protect is from attackers impersonating the legitimate requester API and sending a request to the receiver API pretending to be him in a network facing API (IE not localhost only, possibly a local subnet but also possibly through the internet).
  • 1
    What is your threat model? What exaxtly are you trying to prevent/defend against? – TheWolf Mar 31 at 12:17
  • This is an authentication scheme so the main threat will be an attacker trying to impersonate someone else to gain access he shouldn't have – cypher Mar 31 at 12:22
  • Please read our help center, then edit the question to describe (for instance) what the threat model is and what threats you're trying to protect against. Rather than answering in the comments, please revise the post to incorporate that context in a way that reads well for a first-time reader. Thank you! – D.W. Mar 31 at 17:47
  • Added, it's a web facing API with the threat being an attacker trying to impersonate a legitimate user to get access. – cypher Mar 31 at 18:42
  • 2
    @cypher Tip for the future: slow hashing is needed for key stretching (when you have a weak key, like a password). When you generate random key, a simple hash is enough. – Dissimilis Apr 18 at 9:50
1

The main flaw of this concept is that it is totally pointless.

Essentially, what it does is:

  • Requester: Hi, I am going to tell you my random name I just created just for you. Here its hash. [step 2]

  • Receiver: Haha OK, here is your hash back [step 3]

  • Requester: Let me check [step 4]. Cool, the hash you returned indeed belongs to my random name for you. I let you see it now and I will forget it immediately [step 4,5]

  • Receiver: Hey, your name indeed produces the hash you provided earlier. Cool! [step 6] I now finally know your name! [step 7]. Let's get down to business. How can I help?

You claim that

This is an authentication only method

whilst the flow inherently only attempts to make sure that the Requester remains the same throughout the communication — something that HTTPS itself already takes care of.

The point of authentication is to verify that whoever claims they are are indeed that party. This implies that the Receiver either already knows the party (e.g. has its password hash or public key in its database to check against) or is able to verify against trusted third party (e.g. using OAuth). In your scenario, the Receiver does not know the Requester at all, and the fact that it merely tells its name does not authenticate it in any way.

  • I think you missed the part that the webhook URL is consistant across all requests from the same "requester API" - making it act as a sort of user identity and allowing it to "verify that whoever claims they are are indeed that party" – cypher Apr 5 at 7:51
  • @cypher Okay, callback URL can be used as ID indeed, but then what is the point of hashing the random secret if it gets transferred plain text anyway (step 5)? If you accept that your callback URL sufficiently identifies you, then just use the random secret to verify that whoever calls you back is indeed the Receiver API that you initially called: your random secret can be sent to them straight at step 2. Then, using callback URL as ID is itself bad idea: change of ownership of the domain name will essentially transfer to the new owner all your rights within the Receiver API. – Greendrake Apr 5 at 9:03
  • You raise a point about improving it so that the token might be simpler to sent unhashed, that might be true and i might need to have that change but the basic concept of "let's use webhooks callback to provide auth" remains so how is that useless? it might be done simpler but that doesn't make the entire thing pointless like your answer suggest. – cypher Apr 5 at 9:47
  • @cypher Security-wise, the only concern I see with "let's use webhooks callback" is the potential loss of ownership of the domain name. Beside that, what makes it pointless is the lack of strong pros and enough cons: HTTP overhead — two async requests instead of one sync, the need to standardize the proposed protocol etc. You need a strong use-case showing the problems with existing auth methods and how they are solved with yours. – Greendrake Apr 5 at 9:57
  • First of all I consider having no need to store a token\password at all as a strong use case that is required in virtually all other current auth systems but secondly the question is only about any security issues in it... if or not you personally see a use for it is outside the scope of the question. – cypher Apr 5 at 14:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.