4

By signed request I mean something like this (simplified example):

Client creates a sig in his request: $sig = hash('sha256', $api_key.$data); which generates 7409ur0k0asidjko2j for example. He then sends this to his request: example.com/api/7409ur0k0asidjko2j

Now, the receiving server then performs the exact process to perform a match for the sig.

Which is generally more secure, a signed request like this or an HTTP digest auth for the purpose of authenticating requests to an API server? Note we assume SSL is not installed.

Improve this question
10
  • There is no difference between these two - both are transmitted within same request.
    – Andrew Smith
    Aug 12, 2012 at 17:32
  • 2
    You really cannot use TLS?
    – curiousguy
    Aug 12, 2012 at 18:19
  • @curiousguy Well we can but for this example we don't really need to encrypt the whole HTTP traffic just the credentials.
    – IMB
    Aug 12, 2012 at 18:24
  • 2
    @IMB With either method the access key (secret authenticator) is not transmitted in clear text at any time, and is not vulnerable (given it has sufficient entropy). But with HTTP digest, only the user-password pair integrity is protected, not the request itself (unless you are thinking of a different type of HTTP digest, if so please give a reference).
    – curiousguy
    Aug 12, 2012 at 19:39
  • 1
    No. TLS (SSL is over!) is what you use to avoid MITM. But only if you use it correctly: properly validate the server TLS certificate.
    – curiousguy
    Aug 13, 2012 at 18:30

2 Answers 2

Reset to default
3

If the signature covers the whole request, then integrity is guaranteed. Request replay is still a potential threat (think: resource abuse).

With HTTP digest authentication, the request could be modified in transit. You are at the mercy of a MITM (Man In The Middle) attack.

Anyway, you should really use TLS provides transport level security:

  • guaranty of confidentially of payload, not just of password or authenticator (but not payload size! be careful if payload size can reveal useful information)
  • guaranty of integrity of payload (but no guaranty WRT client IP address!)
Improve this answer
6
  • Are there other means of protecting agaist request replay other than SSL?
    – IMB
    Aug 12, 2012 at 18:29
  • 2
    @IMB Obviously, you can try to build your own cryptographic engine yourself. But this is not recommended. Is there a specific reason you are trying to avoid TLS? Just fear that it would be too costly?
    – curiousguy
    Aug 12, 2012 at 18:33
  • Purely scientific purposes, SSL is cheap anyway but this is just for kicks.
    – IMB
    Aug 12, 2012 at 18:33
  • 1
    @IMB You could use a request-id to avoid replay. That would complicate the server code if requests can be reorder during transit: the server would have to keep track of recent request-id, and also have an expiration feature so that old request-id cannot be reused. If requests are dispatched to several independent servers (all shared data is read only), that would imply that frequently modified data must now be shared between servers.
    – curiousguy
    Aug 12, 2012 at 18:57
  • You are right this is complicated and messy. And the log will probably be so big. SSL it is.
    – IMB
    Aug 12, 2012 at 19:15
2

Signing of the request might be better, but you should implement it correctly. The hash(key || data) construction is vulnerable to hash length extension attack and should never be used. Here you have good explanation of this subject: Hash Length Extension Attacks. You should use HMAC for message authentication.

Signing of the request is better than HTTP digest auth, because it could also protect the integrity of data sent in the request.

Improve this answer
1
  • +1 "You should use HMAC for message authentication." Indeed, HMAC is the tool designed by cryptographer for exactly this purpose (message integrity).
    – curiousguy
    Aug 20, 2012 at 16:38

You must log in to answer this question.

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