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.

Linked to: Encrypting a fixed format message?

I need to communicate from Site A, a set of information that will be presented to users of Site A, which when they choose to submit, should travel to my Site B. At Site B, I need to validate that the request indeed came from Site A.

Site A has a secret key that can be used for encryption.

The information that needs to be passed:

// The SiteName must somehow be identified to Site B otherwise 
// I dont know which secret key to use for decryption
$SiteName = "SiteA"; 
$Command = "commandA";
$UserId = "42";
$UserName = "John";
$UserTimeZone ="America/New_York";
$UserCountryCode ="US"
$BookId ="966";
$message = encryptionfunction($SiteName.'-'.time());

Right now, i'm sending all of the above, visible to the user.

Should i be encrypting $Command and other fields and sending only

$SiteName = "SiteA"; 
$message = encryptionfunction($SiteName.'-'.$Command.'-'.$UserId.'-'.$UserName
           .'-'.$UserTimeZone.'-'.$UserCountryCode.'-'.$BookId.'-'.time());

1.Edit

frm: http://stackoverflow.com/questions/5727607/generating-one-time-tokens-via-mcrypt-in-php

i will be providing api keys to my partner sites and they will be using code that i give them to to generate "tokens".

these tokens will be automatically present on forms which the partner sites' users will click on and reach my site. when they reach my site, i will need to validate that they indeed came from a partner site.

how do i validate this? the apikey will be secret, but what is presented in the form will NOT be, so it must not be possible for smart users to reverse engineer my algorithm.

share|improve this question
4  
If you need to "validate" the sender we should be talking about digitally signing the transmission, not encryption. –  Georgios May 2 '11 at 8:34
    
In any case it's not clear what you want to achieve by sending the request formed this way... –  Georgios May 2 '11 at 8:41
    
@Georgios - i want to ensure that the request is coming from the trusted part - Site A –  siliconpi May 2 '11 at 13:23
    
@georgios - please see edit.1 –  siliconpi May 2 '11 at 14:42
    
I dont understand why you seperated this question from your other one? It seems practically identical to security.stackexchange.com/questions/3304/…, albeit with some additional information. Why duplicate them? –  AviD May 3 '11 at 9:20

3 Answers 3

up vote 2 down vote accepted

Taking a look at the question that you linked to, Thomas' answer says it all. You want to sign your messages, and you probably want to use an HMAC to do it. To prevent replay, you should include a mechanism that uniquely identifies each message and prevents it from being processed more than once. A possible answer to that, if the clocks are synched, is to remember the tokens you've processed for the past ten seconds and only process tokens that are five seconds old or younger. That kind of overlap should prevent a race condition.

If your information is meant to be confidential in transmit, sign it before encrypting it.

share|improve this answer
    
i'm missing something - what do i do with this hashed value? –  siliconpi May 2 '11 at 15:08
1  
The HMAC can be sent with the request data. An HMAC can only be created or authenticated if it was created with the secret that your two servers know. –  Jeff Ferland May 2 '11 at 15:57
    
(a) are you suggesting that the HMAC be created by putting all the inputs together? (b) if i'm sending across all those values in plaintext, wouldnt that defeat the purpose of creating this hash? (c) is this HMAC hash any different from a regular hash - md5? –  siliconpi May 2 '11 at 16:08
    
(a) Yes. (b) No. The point of the hash is to authenticate the message. If you need to keep it secret, you can encrypt it too. It is important to prevent a message from being played twice, though. They should include something that expires them. (c) See en.wikipedia.org/wiki/HMAC -- it uses a regular hash, but XORs and appends certain data related to your secret key in the process. –  Jeff Ferland May 2 '11 at 19:22

As already mentioned by @Georgios, if all you want is to validate the integrity of your transmission and the fact that it was generated on site A, then you should look at signing.

Whether to use encryption or not is another case. And it's up to you to decide.

Are you OK with your user seeing the submitted data in plain text? I suppose so, as I assume it's mostly user-generated input that gets transmitted either way (correct me if I'm wrong).

You may want to encrypt this data to circumvent eavesdropping on the way to site B, but it's your call to decide if it's worth the added overhead.

share|improve this answer
    
I do want to validate the integrity of my transmission. how do you suggest i do that? i've already sent across secrey keys to site A clients @Karol –  siliconpi May 2 '11 at 13:15
    
I'm not sure I understand correctly. What are site A clients? I think what you want is to keep secret key at site A, create the request and sign it on site A, transmit to site B (be it directly or by user form interaction) and verify the signature upon reception on site B. It would help if you provided some more background on your situation by editing your question (how does site A interact with site B, what's the user part in this etc.). –  Karol Piczak May 2 '11 at 13:56
    
please see edit.1 –  siliconpi May 2 '11 at 14:42
    
It seems as OAuth should suit your needs. Or just stick with @Jeff's suggestion. –  Karol Piczak May 2 '11 at 17:17

You are making the mistake of confusing authentication with encryption. You need integrity protection, not secrecy. Authentication provides integrity protection. Encryption provides secrecy protection. You want authentication. There are two categories of schemes for authentication: symmetric-key authentication (a message authentication code, e.g., AES-CMAC or SHA256-HMAC) or asymmetric-key authentication (a digital signature, e.g., RSA or DSA signatures). Given that you have multiple partner sites, I suggest that you use a public-key digital signature, such as a RSA signature, and not symmetric-key authentication.

To make it simple: Use a RSA digital signature. Site A signs the information using a private RSA key known only to Site A. Site B verifies the information using Site A's public key (which is distributed to everyone).

You should sign every field.

share|improve this answer
    
@DW - can i not encrypt every field and send that across? if i am able to decrypt it fine, wouldnt that be proof of 'authentication'? taking it further, why cant i encrypt everything as one value? –  siliconpi May 4 '11 at 6:51
1  
@Frank, good question! The answer is: no, not really. You'd think that just encrypting would be enough, but oddly enough, it's not. Encryption does not necessarily provide authentication, even though it's natural to think it should, and this misconception has led to a number of serious security failures in widely deployed systems. (That said, there are some encryption schemes which do provide authentication: they are generally known under the term "authenticated encryption". However, they're slightly esoteric and it's less common to find them in an crypto library.) –  D.W. May 5 '11 at 5:33

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.