4 ms·
~"We encrypt sensitive data at rest. And we store decryption keys on our user facing app servers so that apps can decrypt the data. Cool, right?"
by flavor8 8y ago
~"We encrypt sensitive data at rest. And we store decryption keys on our user facing app servers so that apps can decrypt the data. Cool, right?"
- londons_explore 8y agoLets be honest, all reversible encryption schemes are some version of this...
- willvarfar 8y agoI'm not quite sure whether irreversible encryption is a thing in this context (its sometimes used to talk about e.g. password storage, but I think that's a very different use-case), so I'll sally in with an interesting tangent: https://en.wikipedia.org/wiki/Homomorphic_encryption https://en.wikipedia.org/wiki/Homomorphic_encryption Homomorphic encryption is a form of encryption that allows computation on ciphertexts, generating an encrypted result which, when decrypted, matches the result of the operations as if they had been performed on the plaintext. Homomorphic encryption can be used for secure outsourced computation ...
- brianberns 8y agoThat's interesting, but how do you prevent bad guys from "generating an encrypted result" that you don't want?
- heavenlyblue 8y agoIf the variant of the homomorphic encryption you are using is secure, then the bad guys can not generate specifically crafted cyphertext that would decrypt into the result they specifically want.
- lawnchair_larry 8y agoThis doesn’t really exist yet.
- ams6110 8y agoNo, not the "we store decryption keys on our user facing app servers" part. The decryption should happen on back-office payment processing server, with the keys held by a hardware security module. Or better yet don't store the card details at all, but there are valid business reasons that is sometimes necessary.
- jermaustin1 8y agoIn my early days, I had to write a payment processor and it pass a PCI "inspection." TL;DR - PCI compliance was a joke in my experience. The payment page didn't log requests (made figuring some things out hard), it submitted the encrypted card data (public key) to another server through the firewall with only a single non-standard port open, to the data store with write only access. There was then a trigger on insert that would launch a small console app that passed the decrypted (private key stored locally) card and charge information to Authorize.Net, if successful it would then write a success to the charges database, and send that charge identifier to the application's data store. Only access to the payment server was from behind the firewall over RDP and MSSQL over non standard ports. Just the description of this satisfied the PCI guy, and no physical inspection of the hardware was ever done. I'm not sure if what I did was best practice, and I was always so scared it would get hacked. Thankfully after so many fraud charges that my boss couldn't handle the $15 chargebacks we switched to paypal and I no longer had sleepless nights.
- ppierald 8y agoI would agree with this sentiment, however, there are a number of things that you can to to make the job of the attacker harder, or to notice internally when there is inappropriate usage. Service abstractions to encrypt/decrypt the data will limit the surface area where you might store keys. Logging usage to know what operations were made. Also, you can use a system like vault such that the keys are not extractable to do all the crypto operations offline thus massively increasing the chances you would detect such a breach / unauthorized access.