0

I have a set up like this: Payment Server (PS) <> Front End (FE) <> Client JS.

I need to get some data from the Client JS to the PS, without the FE being able to modify it and have PS prove that correct. In this situation, the FE acts as store and forward (with some basic validation of the payload).

This is my plan:

  1. When setting up their account, the user enters a PIN. This is hashed by the JS and the hash sent to the PS via FE for storage. It is not stored in the FE and PIN itself not seen by PS or FE in plain.

  2. When required, the JS creates the JSON payload as normal. The user enters their PIN and this is hashed in the same way as when created.

  3. JS takes the payload, the hashed PIN and nonce (which was previously sent by the server in an initial communication), and creates a HMAC-SHA256. This is sent, alongside the payload, to FE, validated/sanitised and then forwarded to PS untouched.

  4. PS checks HMAC-SHA256 is unmodified, authenticated and nonce is unused, using own stored PIN hash.

  5. When PS returns back to the JS with it's own result, it can do the same thing and JS can confirm the return is also authentic and unmodified.

Does this sound viable? I am aware a PIN is generally quite short, say 4 characters minimum. Is there anything I can do to help strengthen that?

Paul
  • 527
  • 4
  • 8
  • Why are you using hmac instead of digital signatures? – atk Oct 19 '14 at 03:08
  • @atk Would you mind elaborating? AFAIK, digital signatures requires a certificate and that's not an option. Isn't the process pretty similar, but encrypts the data too? If so, that isn't an option as I would still like the FE to do some basic validation of the data before passing through. – Paul Oct 19 '14 at 08:34
  • Edited question to show preferable to see data and not have it encrypted. – Paul Oct 19 '14 at 08:49
  • that still doesn't answer why you chose an hmac/shared key over a digital signature (private key). – atk Oct 19 '14 at 11:39
  • @atk I am happy to use digital signatures if that is an option, but doesn't it need a certificate? Wouldn't it make it more complicated than using a PIN? I didn't 'choose' hmac, it was the only way I know. – Paul Oct 19 '14 at 19:42
  • Yes, it needs a certificate, but you can generate certificates with or without an external certificate authority. It will be substantially stronger than a PIN and will not suffer from transmitting a secret key around (or weak PIN based key generation). – atk Oct 19 '14 at 21:41
  • Actually, correction: it needs a private/public key pair that you trust, which is most commonly accomplished with a certificate. You can establish trust another way if you absolutely have to. – atk Oct 20 '14 at 04:20
  • I see, I don't think that would be suitable for the pop up then as the user isn't going to use the same machine, browser etc each time and I can't see that the user would move it from place to place. However, that sounds like it would be great for a Android/ios app. Thank you. – Paul Oct 20 '14 at 08:49
  • You still have to share the secret key every time... what are you trying to protect against with your hmac scheme that wouldn't be better implemented by just using tls? – atk Oct 20 '14 at 11:32

0 Answers0