Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
    
There is no difference between these two - both are transmitted within same request. –  Andrew Smith Aug 12 '12 at 17:32
1  
You really cannot use TLS? –  curiousguy Aug 12 '12 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 '12 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 '12 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 '12 at 18:30
show 5 more comments

2 Answers

up vote 2 down vote accepted

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!)
share|improve this answer
    
Are there other means of protecting agaist request replay other than SSL? –  IMB Aug 12 '12 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 '12 at 18:33
    
Purely scientific purposes, SSL is cheap anyway but this is just for kicks. –  IMB Aug 12 '12 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 '12 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 '12 at 19:15
show 1 more comment

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.

share|improve this answer
    
+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 '12 at 16:38
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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