Security Testing

Where to have security features tested?

[inveni0]

Hello.

I'm enhancing the security of a website we're developing, and I want to add an extra layer of obfuscation to the already-PCI-compliant encryption we're using to store credit card numbers. The idea is to add an extra layer of protection, so that the numbers are more secure if the database is hacked by some means (which is happening more and more commonly around the web every day).

Currently, the numbers are encrypted and stored, but I want to use a dynamic key (different for every number) so that a batch of numbers can not be easily decrypted. (For instance, a hacker could, with relative ease, feed an array of encrypted numbers into a script that would compare all of them and reverse engineer the key accordingly, exposing all card numbers.)

By adding an extra layer of obfuscation and using a dynamic key that is dependent on a certain step within this layer of obfuscation, we hope to exponentially increase the amount of time it would take to crack the credit card number encryption.

My question is this: Where can we go to have skilled mathematicians and programmers attempt to reverse engineer the numbers?

I'd like to see how easily the obfuscated numbers can be reverse engineered (before being encrypted). This will help determine if the extra layer is helpful or harmful.

Thanks!

[phranque]

you should be looking for services such as internet security assessment consultants and certified ethical hackers.

[Kendo]

How come they are getting your records so easily and what type of database is it? Is the db hosted remotely or local?

[incrediBILL]

That's cute and all that but you're better off not store the CC #s in the first place.

Isn't the transaction being processed in real-time?

If so, what do you need the CC # for?

I quit storing them about 10 years ago as my CC processor provides back-end tools that allow me to make adjustments, credits and refunds without needing to have the CC # whatsoever which makes the site completely safe for shoppers.

What you should also know is when hackers get into your site, if you have any code on the server that can decrypt the CCs for admins to look at them, they can also decrypt them. What most hackers do is just drop a line of code in your ecommerce checkout process that sends them the CC #s in real-time as they are being submitted thus bypassing all encryption. Trust me, I used to be a web host and I've seen it all.

The only way not to compromise CC#s is to NOT save them but if you do, they should be downloaded off the server frequently and purged from the server after downloading.

YMMV

[inveni0]

@phranque
Do you have any recommendations?

@Kendo
They aren't getting the records easily. The database is remotely hosted, but since it is accessed, I imagine that it is also vulnerable, and that's why I want to add an extra layer of encryption.

@incrediBILL
Please don't lay into me with the usual "what are you stupid enough to do that for" business. I don't have the patience. This is a website used for a purpose that requires the storing of credit card numbers. If it could serve its purpose without storing numbers, then of course it wouldn't. But it must. Thankfully, there is something called PCI Compliance, which the site adheres to completely, exceeding its level of security in many places. PCI compliance is in place because credit card numbers sometimes need to be stored. Do you think your credit card processor doesn't store them? They do, because they need to. We also need to store them, and that's why as much extra security and obfuscation as possible is good for the application. In fact, many competing sites don't even meet PCI compliance in the first place--by doing things like storing not just the credit card number, but also the security code on the back.

I understand that there is always a hack. Even major corporations like Sony, LivingSocial, Microsoft, etc, etc, have to deal with exploits. That's the nature of information.

My goal here is to simply layer another line of protection into the procedure, so that the application we run offers another step above the minimum security requirements. So I'm looking for people to attempt to reverse engineer the new layer of protection. It will serve as another layer against the basic SQL exploits, if one exists.

[incrediBILL]

First, chill, nobody is saying ""what are you stupid enough" or anything else, just pointing out there are often ways around it. Wish I knew your specific application as I've helped many sites side step CC storage.

I'm well aware of PCI compliance as I wrote a commercial ecommerce package that was on the market for 8 years, been there, done that. Implemented more payment gateways and worked with more payment processors than I'd like to admit. I've also watched site owners get into all sorts of trouble even when they were strictly in PCI compliance as Visa can get cranky and force you to put a $30K escrow account on your merchant account (or more) and they simply take that money out of your sales if you can't post the escrow funds directly.

I think you misunderstood my point in that if you plan to store them you must plan to use them, which means they must be decoded and I assumed that would happen on the server, meaning the script and code used to decode them would also be on the server which in the event the server gets hacked the hacker could use to also decode them therefore making the whole exercise of tweaking the encryption fruitless.

If you were using a CGI cart, something running compiled code, then I'd have a different opinion because the methods wouldn't be simply sitting there in script for the hacker to see.

If it's recurring billing, even that can be done without storing CCs.

If you must store CCs, I would keep them 100% separate from the member account and use some hashing scheme to relate the member account with the card number itself so that if a hacker downloads just your member data that they wouldn't get the card numbers. I would call the database something obscure like "profilebitmap" or something to throw them off the trail. Depending on the size of the client, I'd also consider doing what I did for one client which was separate the front end server from the databases altogether as the front end web server is usually the easiest to hack. If all they can do is mount and query the database from a backend server that has ZERO web access the odds of getting your database hacked are even less but not impossible.

BTW, be careful and don't leave CC data in sessions which is a common mistake many programmers make as harvesting session files can give someone a bunch of unencrypted cards in a hurry. I always pass the CC variables directly from SSL secured browser page to SSL secured browser page so it's only in the customer browser until they hit submit, then it's passed directly to the payment processor and discarded. Never stored on my server ever.

FWIW, our software used to just store them using standard SSL encryption with a different private key per website so even getting the key and hacking one site didn't allow them to decrypt all the sites and we never had a problem doing it that way. That's why I mentioned hackers dropping a line of script into the site to send the CC#s during the submit payment process as that's the only way they could get them without the private key to decrypt the card #s in admin.

Hope that helps and if you want some out of the box thinking on how to possibly avoid storing them, let me know more about the application as I know lots of different US payment processors that do some interesting stuff with APIs.

[inveni0]

The credit card numbers have to be recalled for later entry into a separate credit card processing terminal. The system will also be designed to process the numbers through an online gateway, but the bulk of the clients using this administrative software will not be set up to handle payments in that manner (as they will prefer to process the credit cards at a date TBD). So storage is, unfortunately, necessary.

No credit cards are stored into sessions. They are obfuscated in javascript and posted via SSL to a PHP script that immediately encrypts the card data using additional obfuscation and a dynamic key/salt/hash system. All cards are encrypted using a different key, meaning the only way to figure out how to decrypt the data would be to hack the server and steal the script that decrypts it. So server security is of paramount importance (as it should be).

I hadn't thought of using a compiled script to encrypt/decrypt the information, though. I'll be looking into that immediately, as it will further secure the encryption algorithms being used. The only issue I see with it, however, is that once a hacker knows what to pass to the script and how to read the return, there is no stopping them from accessing it. It's just the nature of the beast, I'm afraid. Even a bank can lock up all of its money in a timed vault, but that won't stop a determined criminal from getting the money.

Again, this is not the fix-all for security. It's just a wrench in the hacker's plan.

I'm looking now for some certified ethical hackers, as that seems to be my best bet for seeing how difficult it is to reverse engineer the card encryption. My goal is to make reverse engineering the card numbers harder than hacking the server.

[Kendo]

I quit storing them about 10 years ago as my CC processor provides back-end tools

Same here. Ever since we received an online order for a laptop purchased using the credit card of one of our hosting clients. That did not go down well at all.

But there is alternative. Paypal caters for periodic debits.