Change Credit Card Encryption Hash

[griffe]

Hello,

 

How do I change the Credit Card encryption hash? Just change it?? Or do I have to generate one specially??

 

I know I may not be able to read any current cards in the system if I change it... I only care about new cards..

 

Thank you.

[sparky]

change it in configuration.php

[drhcanada]

is there a way to occasionaly change the hash for the stored CC data while changing the encrypted card numbers to be available under the new hash?

 

perhaps a script that converts the CC data from one hash to another?

 

even outside of WHMCS and directly through the mysql database?

[sgrayban]

is there a way to occasionally change the hash for the stored CC data while changing the encrypted card numbers to be available under the new hash?

 

perhaps a script that converts the CC data from one hash to another?

 

even outside of WHMCS and directly through the mysql database?

 

nope -- that's why its a hash to keep CC data secure

[bear]

If you change it, the existing numbers will not be decipherable, I'd imagine. Proceed with caution, and record the old one before you begin in case it needs reverting. Of course, any encrypted with the new one won't be usable after converting back...

[drhcanada]

nope -- that's why its a hash to keep CC data secure

 

I know

that why I was wondering if there is a way to do a hash change

 

enter old hash,

enter new hash.

system goes through each stored credit card and changes from old to new hash.

 

would be nice to have such a feature. means the hash can be changed more often to ensure less chances of it be decrypted in the future.

[sgrayban]

Because of PCI rules I highly doubt this will ever happen. The reason for a HASH is to make sure the data will always be private and hashed with a very long and obscure string.

 

There is no need to keep changing the hash for the CC data if you use something that is obscure. Say 28 characters with all sorts of characters like -> #$#@!2345GGRWewss*$$

Edited April 11, 2010 by sgrayban

[bear]

like -> #$#@!2345GGRWewss*$$

/bear steals sgraybans CC hash

Ironically, that's considerably shorter than most of my server passwords.

 

I can't see how this is any more against PCI compliance than the ability to decrypt on the server in the first place. It's my understanding that CC numbers, in order to comply, should not be stored on public facing systems, encrypted or not. The risks of them being compromised and decrypted are increased many times over by the fact that the key to reverse the card is stored in a known location in every WHMCS installation, regardless of the key length. Yes, the encryption methodology is within encrypted code, but a smart hacker could (and probably has already) worked that out.

 

I'm not knocking the WHMCS system as I think it's terrific, but storing CC numbers is risky.

I think I'd only be comfortable with this if the encrypted CC number was only stored on my PC, and that was what would be pasted into a form to decrypt instead of the key, or perhaps a desktop tool for that. I used to use a PERL cart script called Quikstore (not the most recent version of that which is very poor), and it had a simple encryption tool on the server, and a desktop decryption tool to reverse it. It used a public key to encrypt and email an order, and required it's matching local and private key to convert it back. For all it's faults, that cart got it right, I felt.

[sgrayban]

/bear steals sgraybans CC hash

Ironically, that's considerably shorter than most of my server passwords.

 

heh

 

That was just an example. The user(s) can get much more creative then I did, 256 key hash.

 

My point is this.... if you are so worried about your CC hash getting compromised why are you even storing the CC info in the first place ?

 

Constantly changing it is only going to upset your clients because they have to re-enter it every time you make a new hash including the OLD clients not just the new ones.

[valorin]

Constantly changing it is only going to upset your clients because they have to re-enter it every time you make a new hash including the OLD clients not just the new ones.

 

Hence the need for a way to change the hash and convert the currently stored credit card details to the new hash.

 

I am working on making our WHMCS installation PCI-DSS compliant and I have this problem:

 

Most of my company have the CC hash stored on their computers. If any of these staff members go rogue and keep the cc hash when they leave the company, they can decrypt all the CC details if they ever get access to the system.

 

I want to update the db with a new hash, which will not be passed around, and only accessible to people with direct access to the box. Thus ensuring that only staff I trust can decrypt CC details, AND I can roll out new hashes whenever I need to (i.e. when staff members leave) as an extra security precaution.

 

Sound obsessive? Yes, it might be.

But after reading the PCI-DSS compliance documents, it's a requirement for us.

 

I actually have a plan to write a script which will do this for me. It's not going to be pretty, but it is possible - I've decrypted the CC details before.

[Niklas]

Correct me if i'm wrong, but isn't the stored CC information encrypted rather than hashed?

 

If that is the case, then you simply loop through each stored card, decrypt the info it using the old key and encrypt it using the new key and then store the new encrypted value.

 

I'm not sure if such script exists in the public, but we're talking something that can be done with 10 lines of coding, so it shouldn't be that difficult if you have some coding experience.

[valorin]

Niklas, have you actually tried? I have.

 

The WHMCS code is fully encrypted, and unless I missed something obvious, we don't know what or where the encryption function is stored within the code to use it independently of WHMCS. If I either knew what the encryption function was, or how to easily access it, then yes it would be a piece of cake.

 

Care to fill me in on the secret so I can write these 10 lines?

[sparky]

guys... be aware that the encryption hash is also used in the user login passwords so if you change it you will also need to update all of the user passwords. Else you may have alot of tickets "I can't log in and my password is correct"

[valorin]

guys... be aware that the encryption hash is also used in the user login passwords so if you change it you will also need to update all of the user passwords. Else you may have alot of tickets "I can't log in and my password is correct"

 

Damn! I forgot about that... this just gets more annoying.

Ah well, I'll have to rip it out along with the credit card details in my script.