4 ms·

It is a good way to track customer's buying habits. eg how many people go weekly, or to different stores, or buy same products etc. eg HomeDepot tracks credit c

by rb808 9y ago

It is a good way to track customer's buying habits. eg how many people go weekly, or to different stores, or buy same products etc. eg HomeDepot tracks credit card back to userid https://consumerist.com/2013/01/16/home-depot-sort-of-explains-how-an-in-store-purchase-can-result-in-e-mails-from-its-website/ https://consumerist.com/2013/01/16/home-depot-sort-of-explai...

tzs 9y ago
For that it should be good enough to just store the first 6 digits and the last 4 digits of the card number. You might occasionally get two different customers whose first 6/last 4 are the same but it should not happen often enough to be a significant issue. If even that small risk of conflating two different customers is too high, you could go with a hash of the credit card number. If you go with the hash, then don't ALSO store first 6/last 4. A typical credit card number is 16 digits, and one of those is a check digit. If someone gets a hold of the hash, and first 6/last 4, then there are only 100 000 possible values for the missing 6 digits (10^5, not 10^6, because for any guess for 5 of the digits there is only one possible 6th digit that will make the checksum work). Unless you use a very very slow hash function, brute forcing 100 000 possibilities will be quick.
- KGIII 9y ago
  The first four digits are pretty generic. They tell you who issued the card. Many people will have the same first four digits. Maybe the second set of four and the last set of four would be better? Usually the first four is the issuer and whatever numbers signify the specific type of card. The next set is the bank, I think. The third set is, as I recall, the account number, and the last numbers equate to your routing number. Actually, just the last eight digits should be adequate. Hash them with a salt based on the last name and collisions are very, very unlikely. Don't store them at all, just store the hashes.
  - lloydde 9y ago
    I can’t tell if you are playing, but by storing the most unique part of the credit card with last name you are not reducing the desirability of the target much.
    - KGIII 9y ago
      You don't store the name. You use the name to generate the salt and hash the results. You only store the hashes.
      - lloydde 9y ago
        You are still doing a near lossless transformation of the unique part of the credit card and name as one of your goals is zero (minimized) hash collisions. The character set and length of the input plus reasonable assumptions about the salt and hash make it very likely "reversible" using rainbow tables or other brute force techniques. Choose metadata that doesn't have such high financial value. Additionally, it's been years since I've been involved in e-commerce and the details are now foggy, but if I recall storing those addition credit card digits, even transformed, will prevent you from achieving the industrial certifications.
yellowapple 9y ago
This is what hashing is for.
- coredog64 9y ago
  RSA sells a very nice hardware device that will tokenize credit cards such that it's safe to store the tokenized value _AND_ you can detokenize it in order to charge (or refund) the card.

by rb808 9y ago

tzs 9y ago

For that it should be good enough to just store the first 6 digits and the last 4 digits of the card number. You might occasionally get two different customers whose first 6/last 4 are the same but it should not happen often enough to be a significant issue. If even that small risk of conflating two different customers is too high, you could go with a hash of the credit card number. If you go with the hash, then don't ALSO store first 6/last 4. A typical credit card number is 16 digits, and one of those is a check digit. If someone gets a hold of the hash, and first 6/last 4, then there are only 100 000 possible values for the missing 6 digits (10^5, not 10^6, because for any guess for 5 of the digits there is only one possible 6th digit that will make the checksum work). Unless you use a very very slow hash function, brute forcing 100 000 possibilities will be quick.

KGIII 9y ago
The first four digits are pretty generic. They tell you who issued the card. Many people will have the same first four digits. Maybe the second set of four and the last set of four would be better? Usually the first four is the issuer and whatever numbers signify the specific type of card. The next set is the bank, I think. The third set is, as I recall, the account number, and the last numbers equate to your routing number. Actually, just the last eight digits should be adequate. Hash them with a salt based on the last name and collisions are very, very unlikely. Don't store them at all, just store the hashes.
- lloydde 9y ago
  I can’t tell if you are playing, but by storing the most unique part of the credit card with last name you are not reducing the desirability of the target much.
  - KGIII 9y ago
    You don't store the name. You use the name to generate the salt and hash the results. You only store the hashes.
    - lloydde 9y ago
      You are still doing a near lossless transformation of the unique part of the credit card and name as one of your goals is zero (minimized) hash collisions. The character set and length of the input plus reasonable assumptions about the salt and hash make it very likely "reversible" using rainbow tables or other brute force techniques. Choose metadata that doesn't have such high financial value. Additionally, it's been years since I've been involved in e-commerce and the details are now foggy, but if I recall storing those addition credit card digits, even transformed, will prevent you from achieving the industrial certifications.

yellowapple 9y ago

This is what hashing is for.

coredog64 9y ago
RSA sells a very nice hardware device that will tokenize credit cards such that it's safe to store the tokenized value _AND_ you can detokenize it in order to charge (or refund) the card.