bin2hex / hex2bin help

[bdeverea]

I'm building a system which will allow me to encrypt and store credit cards in a MySQL DB. The encrypting and decrypting parts I have no problems with, however in order to store the number in the DB I need to perform a bin2hex conversion.

I am using a hex2bin function that I found somewhere on this site, to convert the stored, encrypted number back to hex, however when I perform these functions I am only getting half of the number converted (the first 8 digits). I am posting the code, any guidance or help is greatly appreciated.

//convert hex string to binary string (used in decrypt_data)
function hex2bin($data) {
	$len = strlen($data);
	for($i=0;$i<$len;$i+=2) {
		$newdata .= pack("C",hexdec(substr($data,$i,2)));
	}
	return $newdata;
}

thanks!

[AstroTeg]

Guidance: Never ever never store credit card numbers. Period. If you have to store it, then you're probably doing something wrong. If you wish to use the card number as a means of validating the user and the card they used, then store the last 4 digits of the card number.

It doesn't seem like it was a good idea to post the encrypt/decrypt code as well.

[bdeverea]

Thanks AstroTeg for the quick response. I did remove the encrypt/decrypt functions at your suggestion.

In regards to storing cc numbers, because I cannot charge the cards until the order is filled and shipped I need a method to store the cards in order to verify them first, then charge them later.

Is there a better method to do this than storing them in a DB? Keep in mind that a project manager will be charging the cards at a later date.

thanks again.

[AstroTeg]

You shouldn't even be collecting the card numbers - in my opinion. Have the project manager contact the people.

Or better yet, setup credit card processing. If there's a particular reason to wait for billing the card, I'd think the credit card processors (or the bank) would have some possible solutions for you (this may mean you have to read some docs or contact some people).

Otherwise you have the worst-case scenerio which just happened today: You accidentally posted the encrypt/decrypt code making the process available to view the card numbers. That's a good chunk of the puzzle to get the card numbers out.

Another one is someone hacks the web server. They get root access. They browse the databases and determine yours and locate your web files. They download them all for further. They view your PHP code and use your decrypt function to get the numbers.

You have SSL installed and you will be using it, right? If you don't have SSL, then anyone on the network between your server and the client could sniff the traffic and pull card numbers out.

You might also check on the consequences of accidentally leaking out card numbers. I'd figure the credit card companies who belong to the stolen card numbers might try coming after your company for reimbursement for their losses (aka: their customer's losses).

[bdeverea]

Thanks for you help. After reading your posts you've convinced me to not store the numbers in our DB, and I've changed my encryption methods based on my accidental posting of the code earlier.

I am of course using SSL to safely pass the card information to our merchant and they do enable us to verify the card and then charge the amount at a later date.

I would like to enable our users to have their billing information available to them in our checkout process so I wanted to ask you if you see any potential security issues with me saving their info in an encrypted cookie?

Thanks again for your help with this, but I'm still stumped as to why I'm only able to decode half of the stored string. 😕

[AstroTeg]

As for viewing the billing information at checkout, only show them the last 4 digits of the card number. Its enough data for them to figure out which card they used but not enough data for a thug to make use of it.

I'd stay away from trying to encrypt stuff in a cookie which gets sent back to a browser and parked on a hard drive. You could have problems with someone intercepting the data and making use of it. Someone could intercept the data as it sits on the hard drive stored in cookie form. More seriously, someone could hijack the session and starting billing on that card number. Not good if you ask me.

Sessions are typically used in the final phases of the transaction. These are sessions that expire when the web page is closed. Note also its just the session ID being used. That's fine. Just keep in mind session hijacking and how all that works (typical security stuff).

I'd recommend following what your payment gateway (or bank) allows you to do with later payment. Use the last 4 if you have to, but nothing more. As for billing, the user should be able to figure out which card was used. And it should make them feel better that the card number has been blanked out for security.

Seriously, check out how professional e-comm sites work. Buy something. Notice how they handle your card number (notice you don't see it come back to you in an email, shown more than once on a web page, etc). Think about how you'd want your card number handled. Just be careful...

[devendra_denu29]

Hey ....I think you have problem with the size of the column.

Please take look of your column size in which you are inserting value and fetch.

Hope this will help you out.

thanks