3 ms·

I heard a commercial for Lifelock the other day. The hook was something like "Big news in identity theft! There hasn't been a major breach in a couple weeks..."

by Varcht 13y ago

I heard a commercial for Lifelock the other day. The hook was something like "Big news in identity theft! There hasn't been a major breach in a couple weeks..." Something needs to be done to prevent this. I wonder if it would be feasible for the Credit card companies to do all the storage of card data as a service for retailers. Retailers would just store a reference token. Until then my credit is frozen[1] 1. http://www.clarkhoward.com/news/clark-howard/personal-finance-credit/credit-freeze-and-thaw-guide/nFbL/ http://www.clarkhoward.com/news/clark-howard/personal-financ...

Cherian_Abraham 13y ago
What you are talking about is essentially the tokenization concept which should become real in 2014. All retailers such as Amazon would become Token requestors in this concept. Advantages would be to essentially make these breaches irrelevant as tokens could be invalidated quickly by the card issuers easily. Further, for merchants - the advantage would be reduced fraud and hopefully better interchange economics.
- jimktrains2 13y ago
  A lot of processors have offered that service for years. Amazon, being their own processor, probably stores their own numbers, but if Visa themselves would start tokenizing, that would be huge and awesome.
- Varcht 13y ago
  Good to hear, I sincerely hope that can get it right.
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.
superuser2 13y ago
The security of credit card information isn't the consumer's problem, thanks to zero fraud liability policies. The worst that happens is you have to use your debit card for a few days while a new credit card comes in the mail. It's typical of the HN ethos to want to take heroic steps to safeguard your personal data and to demand better of the people who handle it, but in the case of credit card numbers, it's really the industry's problem, not ours.

by Varcht 13y ago

Cherian_Abraham 13y ago

What you are talking about is essentially the tokenization concept which should become real in 2014. All retailers such as Amazon would become Token requestors in this concept. Advantages would be to essentially make these breaches irrelevant as tokens could be invalidated quickly by the card issuers easily. Further, for merchants - the advantage would be reduced fraud and hopefully better interchange economics.

jimktrains2 13y ago
A lot of processors have offered that service for years. Amazon, being their own processor, probably stores their own numbers, but if Visa themselves would start tokenizing, that would be huge and awesome.
Varcht 13y ago
Good to hear, I sincerely hope that can get it right.

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.

superuser2 13y ago

The security of credit card information isn't the consumer's problem, thanks to zero fraud liability policies. The worst that happens is you have to use your debit card for a few days while a new credit card comes in the mail. It's typical of the HN ethos to want to take heroic steps to safeguard your personal data and to demand better of the people who handle it, but in the case of credit card numbers, it's really the industry's problem, not ours.