4 ms·

It would be tragically easy for each credit card company to give each retailer a different Curve25519 public key and keep all of the private keys. The retailer

by KMag 13y ago

It would be tragically easy for each credit card company to give each retailer a different Curve25519 public key and keep all of the private keys. The retailer could immediately encrypt the CC number using Curve25519 and AES-256 as soon as they got it, requiring 48 bytes of storage. One or two more bytes (or a variable-length integer) would store which credit card company the token is good for. That way, each merchant can generate its own tokens without having to interact with the credit card companies, and any stolen tokens can only be used to make fraudulent charges with the same merchant from which they were stolen.

hga 13y ago
I would add in all seriousness that: "It would be tragically easy for many retailers to not immediately encrypt the CC number using Curve25519 and AES-256 as soon as they got it, or take years to move to this, etc." Although anything that, if properly used, would massively decrease the attack surface and localize the consequence of a breach, would be fantastic. Right now the attack surface is just too damned big. Hmmm, to prevent another Target, wouldn't each POS card acceptor need firmware or hardware changes to do this action "immediately"?
- jimktrains2 13y ago
  The issue with target wasn't someone intercepting between the reader and the terminal. The terminal, or heck, even the store's servers, could do the encryption and it wouldn't be terribly difficult or time consuming to do (as opposed to firmware upgrades).
kabdib 13y ago
"Tragically easy" in the case of a large government deployment of software probably means "a few years of study, about a hundred consultants, and a bunch of custom COBOL and Java written by people who can't spell XOR and think that ROT13 is overkill." The encryption algorithms you use are the least interesting piece of the puzzle: Just use something strong enough. It's the key management, data flow, storage and access security (both physical and via computer) that this kind of thing falls apart on. You really need security all the way from the reader, which is (sort of) what chip-and-PIN is.

by KMag 13y ago

hga 13y ago

I would add in all seriousness that: "It would be tragically easy for many retailers to not immediately encrypt the CC number using Curve25519 and AES-256 as soon as they got it, or take years to move to this, etc." Although anything that, if properly used, would massively decrease the attack surface and localize the consequence of a breach, would be fantastic. Right now the attack surface is just too damned big. Hmmm, to prevent another Target, wouldn't each POS card acceptor need firmware or hardware changes to do this action "immediately"?

jimktrains2 13y ago
The issue with target wasn't someone intercepting between the reader and the terminal. The terminal, or heck, even the store's servers, could do the encryption and it wouldn't be terribly difficult or time consuming to do (as opposed to firmware upgrades).

kabdib 13y ago

"Tragically easy" in the case of a large government deployment of software probably means "a few years of study, about a hundred consultants, and a bunch of custom COBOL and Java written by people who can't spell XOR and think that ROT13 is overkill." The encryption algorithms you use are the least interesting piece of the puzzle: Just use something strong enough. It's the key management, data flow, storage and access security (both physical and via computer) that this kind of thing falls apart on. You really need security all the way from the reader, which is (sort of) what chip-and-PIN is.