Option for not storing credit card hashes on the server

[bear]

If the key/method to encrypt is on the server and it's made possible to reverse it, someone could figure that out, most likely.

[drhoo]

If the key/method to encrypt is on the server and it's made possible to reverse it, someone could figure that out, most likely.

The key and the method are not the same thing. Many strong methods are actually open source. With symmetric encryption (having just one private key) you get a pretty good security.

The whole point of this thread is the option of not having your key on the server and hence the passphrase solution.

[disgruntled]

The whole point of this thread is the option of not having your key on the server and hence the passphrase solution.

Ok, a more constructive response, my last one seemed to go over your head a little.

You say a passphrase and no key stored on there server, this is on the surface a good thing, there is no key there is no way to decrypt it.

But now lets talk logistics, Do you manually process payments? if so, your going to be very very busy with 20 clients let alone a few thousand, manual processing takes time, each one a minimum of 5 minutes.

Now there is a solution using your idea but not in the way you would do it, encrypt using your chosen phrase, that is not stored, decrypt with this phrase, but its done when you log in & enter the passphrase, not individually, but in batch, this means once a day, you have to log in to do this. not such a messy over complicated task.

Although this relies on you never being taken ill, having a day off, taking a holiday, forgetting the passphrase or being dead. i dare say a few more instances would come into play but off hand i cant think of them.

There is another solution vaguely working on your method.

You need a hosting account somewhere else, with a cron job set up to run a call home file. lets say this cron job does one thing, takes the encryption key that is now no longer kept in whmcs, and sends it back to your installation once a day, this is all done securely. This means now our call script initiates the cron run no need for the extra cron jon in our installation server, and supplies it the information to decrypt the cards.

No need to remember a key because its stored elsewhere at a location that doesnt matter because it can be located anywhere on the internet and the location can be changed frequently in the time it takes to create a new hosting account. the only thing that matters is the installation server allowing the connection and the remote server being capable.

[disgruntled]

this is to get around bad card processing submissions

Passphrase is setup, the key is encrypted and stored.

The key is kept in config file in its normal decrypted state.

We want to process cards.. we enter the passphrase, the key on the database is decrypted, then checked against the stored, they match, its valid and continue processing, they dont match, return an error message.


This still doesnt eliminate the main problem, and that is, how are you going to get the card data encrypted in the first place. the passphrase is not stored on the server, so it will not be able to be used during the order process. The only way i can see is that you hold all orders until whatever time you log in at to run the cards. This means clients may get service elsewhere in the mean time and cancel their order with you.

If you are storing card data on the server, even for the shortest time, PCI Compliance means you have to encrypt it. it must never be stored in a readable manner. so the idea of holding data for even 5 minutes on its plain format would mean you are not PCI compliant and cannot process cards on your website.

Another thing, if you were allowed to do this, lets say this is 1 client with the card data readable. Do you really want to have to call that client and say.. err you know im really really really really really sorry but your card details have been stolen because i stored them insecurely (you would give full disclosure right?).. again another conversation i would never ever want to have.
1 lost card data is one too many.*

Did you know that 90% of businesses losing data go out of business within two years? did you know 70% of all businesses that lose data go out of business.

Although to be fair, they are talking about hard drive crashes, but dataloss is dataloss no matter how it comes about

[drhoo]

Ok, a more constructive response, my last one seemed to go over your head a little.

You say a passphrase and no key stored on there server, this is on the surface a good thing, there is no key there is no way to decrypt it.

But now lets talk logistics, Do you manually process payments? if so, your going to be very very busy with 20 clients let alone a few thousand, manual processing takes time, each one a minimum of 5 minutes.

Perhaps you don't know this works. What I'm talking about is double-key encryption system and the it's the second key (passphrase) that's never stored on the server. As I said many times before, it's another layer of protection.

This works perfectly fine with batch processing. At the time of processing credit cards (we do it on daily basis), you enter your passphrase and let the computer do the rest for you. You don't need to spend 5 minutes per credit card.

Of course you can write the passphrase for your trusted staff and keep it in a safe place other except the server. What makes you think that I'm the only person who should know the passphrase. I hope you're not going to say now that "what if one of your staff...."

[disgruntled]

Perhaps you don't know this works. What I'm talking about is double-key encryption system and the it's the second key (passphrase) that's never stored on the server. As I said many times before, it's another layer of protection

Well i can only consider that you misunderstand how the passphrase works. if the passphrase is not on the server it cannot be used to encrypt the data, unless you are saying, encrypt it once, then again with your passphrase at a later time.

This might work in a way, but it still breaks automation of card processing.

and giving the passphrase to your staff? this is insane if i may say so, do you know how many "disgruntled" employees take action against the company they work for if they are fired? and im not talking tribunal, but the method of double encryption might be good.

You could add this in your self though, an action hook would take care of what your askin, the one that runs before card processing, make it ask for the passcode and make card processing manual.

[disgruntled]

something like this.

if(!empty($passphrase)) {
    
    $database_key = decrypt_key($encrypted_stored_key, $passphrase);
    if ($database_key === $configs_key) {
      $card_data = decrypt_card_data($card_data, $passphrase);
      // continue with whmcs pre-existing
   }else{
     return $errormessage;
   }

}else{
 // prompt for passphrase
} 

quick and dirty and probably not the right data for the keys but you get the idea

[drhoo]

I'd say you have a look at ClientExec's model and see how they've been using the passphrase. It's not my idea and I've been using it for years.

You always have the problem of human security and disgruntled employees regardless of technology. Any billing staff that takes customer's credit card over the phone is a potential risk. Server admins, your bank employees, police, Matt at WHMCS and potentially anyone other than you is a risk.

[disgruntled]

I'd say you have a look at ClientExec's model and see how they've been using the passphrase. It's not my idea and I've been using it for years.

You always have the problem of human security and disgruntled employees regardless of technology. Any billing staff that takes customer's credit card over the phone is a potential risk. Server admins, your bank employees, police, Matt at WHMCS and potentially anyone other than you is a risk.

Very true, on all counts. i have not used clientexec but i am sure there is a method in doing it, maybe not something i have thought of though.

I already subscribe to the notion, clients should never be on the same server as your website/installation, but i have thought that for quite some time, if a client makes a mess of things and the server comes screeching to a halt, where are they going to turn for support. and that's just one aspect if it.

If we are all compliant with security policies whether taking onsite payments or not, that would go quite some way toward a more secure operation.

I still think that an entirely seperate payment processing server is the way to go though. That and far tighter security measures on all systems.

Business doing well can afford to put out a little extra cost for a sever for just this purpose, now if this could be realised in whmcs we would be onto a winner. Even if whmcs came with the "option" of a remote processing unit this would be a very good idea i feel.

Pass phrases are just a plug in the leak i think. enough time, resources and even pass phrases can be broken, hell i think given enough resources certificates could be broken in minutes.

anyway i am sure we have enough people that use whmcs to throw about some ideas and come up with a real solution.