Sorry, It may be possible that few things are repeated in my question.

I have gone through some documentation/discussion signing an API request and twitter signature documentation

As per the discussion here signing an API request With a signed request the password is kept safe and an attacker cannot use the information in the query to sign another request.

But for signature generation uses SHA-1 non reverting hash function.

My Question is:- If signature used to authorizes /authenticate client request, how that signature used on server side to check and validate the user request?

  • What certificate does the client use to sign the message? You basically need the public part of this certificate to check against the signed hash. Notice SHA-1 is broken, so consider better hash-algorithms (such as SHA-256, 384, 512) – AlexR Aug 26 '13 at 9:48
  • 3
    @AlexR No, SHA-1 is not broken. There have been successful theoretical attacks, in that there are circumstances where SHA-1 does not provide the amount of resistance to brute force that would be expected from a 160-bit hash function, but there is no practical attack against SHA-1, in that you could break a security property of SHA-1 with a feasible amount of computation. – Gilles 'SO- stop being evil' Aug 26 '13 at 10:25
  • @Gilles Let's say, other bit-lengths are safer ;-) – AlexR Aug 26 '13 at 16:00

First off, the use of the term signature here is improper. I know that they are using it in the Twitter documentation, but that's not the correct name. "Signature" normally refers to digital signatures which are part of asymmetric cryptography; i.e. RSA, DSA... Here, we have a MAC.

It is not "SHA-1" which is used, but "HMAC/SHA-1". HMAC is a MAC algorithm which is built around an underlying hash function (here SHA-1) as a building block, but there is more to HMAC than simply a hash function. HMAC is a MAC, which means that it uses a secret key which the Twitter documentation calls the "consumer secret" (yet again, that documentation uses the term "key" to designate something different, which is a great source of confusion). This secret key is involved in the computation; it is needed to produce the HMAC output but also to verify it. This secret key is known to both the client and the server, but to none other (it is "secret"). HMAC is so that each HMAC output is specific to a given input message, and it is not feasible to forge a valid HMAC output for a new message without knowing the secret key, even if many other pairs message+HMAC output are observed.

To sum up, the server can verify the "signature" from the client by using the "consumer secret" which is known to both client and server. When the server sees a valid HMAC output, it knows that the message comes from someone who knows the "consumer secret", which can only be the client, or the server itself. The server knows that it never produces messages with that exact format, so it must come from the client -- the specific client who knows that specific "consumer secret". The client is thus authenticated.

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.