rbhargaw

asked on

# Masking Creditcard information in developlment environment

Is there any best possible solution for masking the Creditcard information in Development Env.

We don't want to use real production data in the dev and also we want to adhere with the PCI standards.

I didn't want any random number coz auditor will anyway think this looks like "real" card number.

I am planning to put "1" from digits 7-15 and need to generate 16th digit to make the card complaint with the MOD 10 alogorithm

but that could potentially also mean we have lot of duplicate cards.

I would need

1. Any code which generates the 16th digit and make the card compliant with MOD 10 algo.

2. Any possible solutions for masking card info in dev

Thanks

Roop

We don't want to use real production data in the dev and also we want to adhere with the PCI standards.

I didn't want any random number coz auditor will anyway think this looks like "real" card number.

I am planning to put "1" from digits 7-15 and need to generate 16th digit to make the card complaint with the MOD 10 alogorithm

but that could potentially also mean we have lot of duplicate cards.

I would need

1. Any code which generates the 16th digit and make the card compliant with MOD 10 algo.

2. Any possible solutions for masking card info in dev

Thanks

Roop

You will have a boat load of duplicates that way which will badly skew any index and really screw up reporting by account/card number.

You can't make random numbers not look like card numbers which, are assigned somewhat randomly as well. All you can do is show the auditor how you generated the random card numbers.

BTW, PCI standards would have you encrypt the column anyway. Without that, you really leave yourself open on the production system. Depending upon what version of Sybase are you using, you can do column level encryption. That way the CC#s are obscured whether they are real or random.

Regards,

Bill

You can't make random numbers not look like card numbers which, are assigned somewhat randomly as well. All you can do is show the auditor how you generated the random card numbers.

BTW, PCI standards would have you encrypt the column anyway. Without that, you really leave yourself open on the production system. Depending upon what version of Sybase are you using, you can do column level encryption. That way the CC#s are obscured whether they are real or random.

Regards,

Bill

ASKER

Bill,

We are encrypting the columns but the 3 of us do have the access. So can we make CC# obsure then?

Thanks

Roop

We are encrypting the columns but the 3 of us do have the access. So can we make CC# obsure then?

Thanks

Roop

You can't get anymore obscured than encryption. If the data is phony and then encrypted, what more do you want.

Just make a pool of random numbers and assign them. The chances that they match an actual card number are pretty small. If you have a million records, each with a different number, you still have a million to one shot of matching an actual card number. Figure 10^6 out of a pool of at least 10^12. Even if you do win the lottery, the expiration date has to match as well and that makes the likelihood a couple of orders of magnitude lower still.

Best of luck,

Bill

Just make a pool of random numbers and assign them. The chances that they match an actual card number are pretty small. If you have a million records, each with a different number, you still have a million to one shot of matching an actual card number. Figure 10^6 out of a pool of at least 10^12. Even if you do win the lottery, the expiration date has to match as well and that makes the likelihood a couple of orders of magnitude lower still.

Best of luck,

Bill

ASKER

The DBA "does not" want to explain to auditors the CC# is not real, if they generated them through Random function. Can we mask the Column say instead of numbers show them as "XXXX....."?

ASKER CERTIFIED SOLUTION

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

ASKER

Bill has given a lot of ideas which will be useful to gather the possible solution.

usual the digits are added from right to left whereas each or each odd or each straight digit can have a weight (a factor). a´fter having this sum, then it could be that from there is done the modulo 10, or it is done from the checksum of this sum. Sometimes, if the last digit of the checksum is 0, some other rules are attached, etc.

so you see many variants possible

meikl ;-)