0

I'm passing sensitive financial data to a payment processor online via cloud functions and would like your expert opinions, please.

The workflow is as follows:

  1. A customer indicates they want to transact by tapping a checkout button.

  2. The checkout button hits an API on the server which generates public and private keys. Both keys are sent to a secured database, keyed by the public key. Only the server has permissions to read and write to the database. The server responds to the client with the public key so the customer can asymmetrically encrypt their data.

  3. The customer enters their sensitive bits into the client on ssl/tls, which encrypts the data with the public key and then sends the data and public key back to the server.

  4. The server fetches the private key from the database using the public key, decrypts the customers sensitive data, deletes both keys from the database, tokenizes the decrypted data, and finally submits the tokenized data to the transactional processor. The client is updated with a callback for the transaction state or error.

Is this a secure procedure? What weak points can I address? What is the technical term for this strategy?

Improve this question
21
  • 5
    this is not e2e encryption if the server is handling the keys.
    – schroeder ♦
    Commented Jan 27, 2019 at 13:50
  • 4
    Please read up on PCI etc. . And making your own encryption inside of TLS is not very useful.
    – deviantfan
    Commented Jan 27, 2019 at 13:52
  • 5
    You do not explain why you want to do things this way and what this scheme is meant to accomplish. I'm unsure what benefit this would have over TLS.
    – schroeder ♦
    Commented Jan 27, 2019 at 13:52
  • 2
    Why can't the server just generate a symmetric key instead of all the key swapping? What does a public/private key scheme do for you?
    – schroeder ♦
    Commented Jan 27, 2019 at 13:54
  • 2
    If we ignore the SSL/TLS, then it sounds like this would provide resistance against a passive attacker, but an active attacker could fairly easily steal the client's sensitive data (basically by substituting their own public key in the server's response, tricking the client into passing their sensitive information with the attacker-controlled public key, then re-encrypting it with the server's public-key to avoid detection). But since you are relying on SSL/TLS, what's the intended advantage of the extra encryption?
    – Nat
    Commented Jan 27, 2019 at 14:39

1 Answer 1

Reset to default
5

On first inspection, I don't see anything egregiously wrong with your scheme, however I question why it's necessary and whether it's actually adding any value.

To summarize @schroeder and @Nat's comments: you are spending a lot of effort to essentially re-invent TLS session encryption from the ground up, and then wrap it inside an existing TLS (HTTPS) session. This seems a little pointless. From the way I read your question, your goal is to have secure data transmission from the user to your server. That's exactly what TLS (HTTPS) was invented for!

If your reason for inventing this scheme is that you don't trust user data to be flowing unencrypted between your TLS endpoint (front-end load-balancer?) and your database, then perhaps your effort would be better spent segregating and hardening your production network.

The usual "Don't Roll Your Own" warnings apply.

Improve this answer
3
  • This is a good answer. So the process is secure with nothing more to address, and if anything, it's a TLS-like strategy (wrapped in a TLS-actually strategy). Thanks for summarizing the thread and dropping an answer!
    – irth
    Commented Jan 27, 2019 at 16:14
  • 2
    @irth You're welcome. If you are going to use this scheme in production, then please have a read through the Don't Roll Your Own thread; unless you've had your custom encryption protocol professionally reviewed / pen-tested, then assume it is easily breakable and don't use it instead of traditional security mechanisms. Crypto is hard to get right, and even subtle bugs can render it completely broken, even for experts.
    – Mike Ounsworth
    Commented Jan 27, 2019 at 16:19
  • :) was just reading through.. checked off the first few. aye, this is an addition to not in lieu of. getting a pen test when it's ready too. sound advice for me and any working with security at all.
    – irth
    Commented Jan 27, 2019 at 16:20

You must log in to answer this question.

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