4 ms·

After I have seen how irresponsibly companys handle these situations, I wonder is it possible to sue them if there is a damage done. Same if someone has identit

by DocG 13y ago

After I have seen how irresponsibly companys handle these situations, I wonder is it possible to sue them if there is a damage done. Same if someone has identity theft. Can the information "leaker" be taken accountable for such thing? Is there a precedent on this?

ljd 13y ago
I used to work on a credit card processing system for a large ecommerce company where my code and I were audited on an annual basis. The fear was always, if there were a breach on our several hundred thousand credit card database it would be trivial to find out that it came from us and it would be VISA that would start litigation against us. I'm lucky enough to never have had a credit card system that I wrote broken into so I couldn't tell you first hand. If anyone wants to know how to make a secure credit card system, it's pretty simple: 1. Don't be creative - there are plenty of rock solid boring implementations that will encrypt your cards. 2. Don't get fancy with encryption or key storage and use strong encryption and a salt and you'll be fine. 3. Limit physical and administrative access to the servers to as few humans as possible. 4. Let the only code that decrypts the cards be the code that is literally right before your call to the gateway. 5. Tokenize your cards, even if it's for an internal project where you think everyone can be trusted. EDIT: As a note, just follow PCI[0] to the letter and you'll end up pretty safe. [0]https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf https://www.pcisecuritystandards.org/documents/pci_dss_v2.pd...
- jimktrains2 13y ago
  The better option, for most places, is to use some form of tokenization where your CC processor stores the CC numbers and hands you an opaque token to store. Much less to worry about on your end as the tokens have no meaning outside the tokenization service. Also, just to reïterate the point: When it comes to security, and you're not a crypto or security person, don't be creative and don't be fancy. Use what works.

by DocG 13y ago

ljd 13y ago

I used to work on a credit card processing system for a large ecommerce company where my code and I were audited on an annual basis. The fear was always, if there were a breach on our several hundred thousand credit card database it would be trivial to find out that it came from us and it would be VISA that would start litigation against us. I'm lucky enough to never have had a credit card system that I wrote broken into so I couldn't tell you first hand. If anyone wants to know how to make a secure credit card system, it's pretty simple: 1. Don't be creative - there are plenty of rock solid boring implementations that will encrypt your cards. 2. Don't get fancy with encryption or key storage and use strong encryption and a salt and you'll be fine. 3. Limit physical and administrative access to the servers to as few humans as possible. 4. Let the only code that decrypts the cards be the code that is literally right before your call to the gateway. 5. Tokenize your cards, even if it's for an internal project where you think everyone can be trusted. EDIT: As a note, just follow PCI[0] to the letter and you'll end up pretty safe. [0]https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf https://www.pcisecuritystandards.org/documents/pci_dss_v2.pd...

jimktrains2 13y ago
The better option, for most places, is to use some form of tokenization where your CC processor stores the CC numbers and hands you an opaque token to store. Much less to worry about on your end as the tokens have no meaning outside the tokenization service. Also, just to reïterate the point: When it comes to security, and you're not a crypto or security person, don't be creative and don't be fancy. Use what works.