I need to implement a web application for user to exchange money. The application needs to invoke API #1 to retrieve exchange rate and show it on the screen for confirmation. And then invoke another API #2 (same API provider) with that confirmed exchange rate to execute money exchange.

To avoid storing state on server and to protect the exchange rate from being modified by the user, what I can think of is that API #1 needs to return a plain exchange rate together with its corresponding encrypted one using symmetric key. Then pass the encrypted one to API #2 for transaction execution.

Am I correct? How to securely implement the encryption? Per-user symmetric key with login name & login timestamp? Or generate a session key randomly for every login session?


There is no need to use encryption since the information is not secret. The important part is instead to protect the information against modification (which is not even provided by all encryption methods).

Since both API's are provided by the same provider a way to do this is to have a secret only known to the provider and then use the secret and the exchange rate together inside a HMAC. This HMAC can then be created by API#1 and send together with the exchange rate to the client. The client will use the given exchange rate and the HMAC when calling API#2 where the server can compute a new HMAC using the provided exchange rate and compare it with the HMAC send by the client. If both match the rate was not tampered with. Implementations for HMAC are available in most common languages. See also Wikipedia:HMAC for more information.

If both API's are not provided by the same party then a shared secret can not be used. In this case one could use digital signatures: The provider of API#1 would create a key pair (RSA or ECC) and publish the public key of it. The private key would be used to sign all messages which need to be protected against modification, i.e. the exchange rate in this case. Everybody who got the public key would be able to verify the signature and thus detect tampering. For more see Wikipedia:digital signature.

  • Thanks for your explanation! How to avoid user record the HMAC generated and the rate pair and reuse them later by passing to API#2? I have another question regarding encryption here. Appreciate for your help. security.stackexchange.com/questions/205945/… – bboy Mar 23 at 16:28
  • @bboy: you can include a timestamp or some expiration time together with the exchange rate. Of course the HMAC or signature should include this timestamp too to protect it against modification. – Steffen Ullrich Mar 23 at 16:56
  • Thanks. For HMAC case, in case the key is shared for message signing purpose instead of just for one field, what is the optimal moment of key generation and optimal lifespan & scope of the key for optimal security? I can think of different cases: 1. Generate a single & forever application key shared by all users; 2. Generate user specific key during user registration by deriving from user password and keep it forever. 3. Generate random key upon user login every time for each user and discard the key when logoff or session expired. 4. Generate random key for each encryption. – bboy Mar 24 at 23:54
  • @bboy: there is no such "optimal" thing. The main part is that the key is only known to the server. Thus any considerations of how often to change the key etc depend only of how long you think you can keep the key secret in your server. – Steffen Ullrich Mar 25 at 6:23

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.