Do you store customers' credit card information in a database or file accessible online? I don't, but I'm curious about how many hosts do.

No way!
I use paypal :D

I don't store any credit card info online, no way. The only thing that my cart system stores online is the customer info and what they ordered, but no credit card info. Not even Authorize.net (Which is my payment gateway) stores full credit card #'s, they have most of the #'s X'd out when viewing my account there. I also use PayPal, which of course doesn't store any of those #'s either.

Best of luck,

David

Absolutely not. To add to this, even the offline info that I must store to charge the cards each month is secured in multiple ways.

For convenience I've often wanted to store the info online but for sanity I wont allow it.

---
If only the credit card vendors themselves would treat the information more securely! but that's a different rant all together..

Not now and never will - Let's hope we are all that responsible. I second that Deb, but why would CC vendor care. They get their money anyway :stickout

I'm not saying that I do store cc's online, but If someone does wish to do so, then that is on them. I don't see anything wrong with it besides parnoyia. If your servers are secure, and such then it shouldn't be something to worry, about nettherthe less, if you store them online, have only the last few digit's available to see ie. xxxx-xxxx-xxxx-1234.

That's just my .02 ;).

It has to be stored somewhere, whether it be on a web server, printed paper or in your head.

I dont see a problem with storing it on a web server so long as you encrypt your data the correct way and have prentitive measures such as firewalls, seperate network, etc. If you are going to store them you better know what your doing!

Where do you think 2checkout, paypal, Authorize.Net store it all..

BTW: I dont store any CC's on my own servers because i use 2checkout

Originally posted by genaldi
Not even Authorize.net (Which is my payment gateway) stores full credit card #'s

Genaldi, you may want to go in and download a group of transactions from Authorize.net. You will see that yes indeed the CC# is there plain as can be. The online screens don't show it, but the download batch certainly does.

On the topic, I would agree that if you have a secure area and use encryption that is would be ok. No matter where you store it someone could get ahold of it who shouldn't. Now it is less likely that someone will break into your office than attempt to hack your server. We currently don't store online, but have been looking at some billing tools that do. All have configurable encryption of course.

eclipsewebs,

I never downloaded a group of transactions through Auth net, I try and stay out of there actually, just go in from time to time to check to make sure things match up with the emails I receive. I'll have to check that out sometime....

*EDIT* - Learn something new everyday. You're right, I just downloaded todays transactions, and sure enough everything is clearly visbile in the text file. I'll still leave them up there, I don't want any of that on my HD or server, it's not necessary...

Take care,

David

CC#s should never be 'stored' on a webserver, in ANY WAY SHAPE OR FORM.... had a client who had been there, done that, and I got the contract to come in, clean house, and set it up properly and securely. ;)

You want to have it stored someplace? Fine. You want it 'changable' via a secure web site? Fine. But for the love of all that is holy, do NOT actually store the CC#s on the webserver machine.

Webserver connected to Internet.
Extra NIC Card in WebServer.
Extra NIC Card feeds direct into a standalone SQL box. (Crossover CAT5 Cable, no need for a hub).
Standalone SQL box has NOTHING else running/open on it besides SQL.
SQL Box ALSO has second nic card in it, that feeds into your local area network, so you can pulled data from it as needed.

Customers order is entered via web into the webserver, order information is stored in table on the SQL Box. Leaving out the CC#... (Store the last four digits in a plain text field if you want the user to be able to see them later via the web)

At the same time, a record is created in a seperate temporary table on the SQL box. This record contains two fields, a reference field (Account#, Order#, Etc), and the full credit card number and exp date, encrypted with a key that is KNOWN To / stored on the webserver (And is thus not 100% secure if someone comprimises the webserver, but we'll get to that)

Cronjob run on the SQL Box (or background process, or MS-SQL Scheduled Event) periodicly (Every 15-30 seconds?!) checks this temporary table for new CC#s that have been updated. If a record exists, the CC#/expdate is taken and encrypted a second time, this time using a encryption key known ONLY to the SQL Server and yourself). This newly encrypted CC# information is now written to the main database table, where it will stay in 'double encrypted' form. The original 'temporary' record you had created is now deleted.

Want buyers to be able to update their info via the web? Fine, take the new CC# info, encrypt it the first time, and pass it into that temporary table as you did the first time, along with the same piece of reference material.. the SQL Cronjob will grab it 15-30 seconds later and re-encrypt it and store it in the database.

To process payment you will need to retrieve the doublely-encrypted CC info and unencrypt it first using the SQL boxes key, and then the 'not-so-uber-secret' key from the webserver. This of course could all be coded into your billing software and automated.

If someone penetrates your webserver, they get the temporary key, and possibly gain a way to tunnel to the SQL box.. but if everything but SQL is locked out on that box, they'll only be able to pull the now 'doubly' encrypted code... which without the 2nd key, is useless to them.

Sorry for the length, but CC# security is one of those things I take seriously, as I said, been there, done that. ;) (The aboslute coolest variation on this I ever setup involved a smartcard having to be present in a reader on the SQL Box for the encryption to take place, they would insert it once a day, run the 2nd encryption phase, and then remove it. Downside: New CC#s sat on the SQL box for up to 24 hours encrypted with only the first key.... Upside: The coolness factor of being the one with the smartcard.. and of course that the actual key was nowhere on the machine itself!)

Originally posted by vSector


Where do you think 2checkout, paypal, Authorize.Net store it all..





ANSWER: We don't.

I can't post on behalf of authorize.net but we don't see any reason to save complete cc information. Archival capabilities are adequate via our processing gateway and only occassionally do we need to go through extra steps to obtain out-dated information or unarchived data.

Additionally you may find that if you are storing data and you are discovered by a cc company to be the source of hacked or illegally obtained cc data you probably won't like the consequences.

We, obviously, prefer to avoid that type of complication. :)

Kristin


:) :)

Shannon, great post!

Yeah, nice post Shannon...

Nice information by Shannon.

good post Shannon. </broken record>

.. i dig the smartcard setup.

Originally posted by RackFive
No way!
I use paypal :D

rotflolol!!!

Hi,

While I can't go into detail on our security, I do need to add that all sensitive customer information (credit card, bank account,etc) is heavily encrypted.

I run my billing system on a private barebone server with encryption

Originally posted by vSector
It has to be stored somewhere, whether it be on a web server, printed paper or in your head.

I dont see a problem with storing it on a web server so long as you encrypt your data the correct way and have prentitive measures such as firewalls, seperate network, etc. If you are going to store them you better know what your doing!

Where do you think 2checkout, paypal, Authorize.Net store it all..

BTW: I dont store any CC's on my own servers because i use 2checkout



We ABSOLUTELY do NOT store CC numbers...neither online or offline.

Originally posted by Shannon

Webserver connected to Internet.
Extra NIC Card in WebServer.
Extra NIC Card feeds direct into a standalone SQL box. (Crossover CAT5 Cable, no need for a hub).
Standalone SQL box has NOTHING else running/open on it besides SQL.
SQL Box ALSO has second nic card in it, that feeds into your local area network, so you can pulled data from it as needed.


Hack into the webserver, and use it to get to the SQL server ..


Customers order is entered via web into the webserver, order information is stored in table on the SQL Box. Leaving out the CC#... (Store the last four digits in a plain text field if you want the user to be able to see them later via the web)

At the same time, a record is created in a seperate temporary table on the SQL box. This record contains two fields, a reference field (Account#, Order#, Etc), and the full credit card number and exp date, encrypted with a key that is KNOWN To / stored on the webserver (And is thus not 100% secure if someone comprimises the webserver, but we'll get to that)


Get the decryption key ..


Cronjob run on the SQL Box (or background process, or MS-SQL Scheduled Event) periodicly (Every 15-30 seconds?!) checks this temporary table for new CC#s that have been updated. If a record exists, the CC#/expdate is taken and encrypted a second time, this time using a encryption key known ONLY to the SQL Server and yourself). This newly encrypted CC# information is now written to the main database table, where it will stay in 'double encrypted' form. The original 'temporary' record you had created is now deleted.


Route 1) Hack into the SQL server, get the raw SQL server data files. SQL servers, for efficiency reasons, do not actually remove the data from the table when you delete it. They will only put a mark on it, as being deleted. Get the password that can be decrypted with the key you get from the webserver, voila, you have the CC#'s

Route 2) Do more digging, and find the 'really' secret key. Decrypt and get the CC#'s


Want buyers to be able to update their info via the web? Fine, take the new CC# info, encrypt it the first time, and pass it into that temporary table as you did the first time, along with the same piece of reference material.. the SQL Cronjob will grab it 15-30 seconds later and re-encrypt it and store it in the database.

To process payment you will need to retrieve the doublely-encrypted CC info and unencrypt it first using the SQL boxes key, and then the 'not-so-uber-secret' key from the webserver. This of course could all be coded into your billing software and automated.


Route 3) Hack to were the billing software is, and use its machanism of decrypting the keys to get the CC#'s


If someone penetrates your webserver, they get the temporary key, and possibly gain a way to tunnel to the SQL box.. but if everything but SQL is locked out on that box, they'll only be able to pull the now 'doubly' encrypted code... which without the 2nd key, is useless to them.


If can't get into the SQL server, then you can only use Route 3.


Sorry for the length, but CC# security is one of those things I take seriously, as I said, been there, done that. ;) (The aboslute coolest variation on this I ever setup involved a smartcard having to be present in a reader on the SQL Box for the encryption to take place, they would insert it once a day, run the 2nd encryption phase, and then remove it. Downside: New CC#s sat on the SQL box for up to 24 hours encrypted with only the first key.... Upside: The coolness factor of being the one with the smartcard.. and of course that the actual key was nowhere on the machine itself!)

Smartcard solution is nice, but there is a better way.

Here is how I would do it. The idea is based on public key encryption, in which there is a public key that can be used only to encrypt the data but not to decrypt it. And there is a different private key than can decrypt the data.

This way you can have both the SQL and webserver on the same machine. You can even use it in a shared hosting environment (to an extent).

Your system will only contain the public (encryption) key. When a client comes and enters his CC#, you encrypt it using this public key and store the encrypted version only.

There is also the private key, which is kept on a CD rom or something similar. Then once everyday, you put the CD in the machine and run your billing routine. It will take minutes (if not seconds) to decrypt all CC#'s it needs and send the requests to the payment gateway. Then you remove the CD from the online machine.

This way the decryption key is only available on the machine during these seconds. You can even disconnect your server from the network while doing this.

As a final step, you can also encrypt the private key itself that is on the CD with a passphase that you should remember, then enter the passphase everytime you do this decryption and payment step. So even if somebody gets the CD, he can't use it.

Originally posted by paypaldamon
Hi,

While I can't go into detail on our security, I do need to add that all sensitive customer information (credit card, bank account,etc) is heavily encrypted.

Just as good as the DeCSS code, or better?

Originally posted by paypaldamon
.. I can't go into detail on our security ..

Why not?

Originally posted by Ahmad
If can't get into the SQL server, then you can only use Route 3.
Smartcard solution is nice, but there is a better way. There's always a better way, and nomatter what you do, armed with a couple tanks, some C4, and say, the army of some small country, we'll get your precious credit card numbers every time, even if we have to kidnap you at night, chop your finger off, and use it to get around the biometric scanner on your SQL box after we crash through the front door of your compound, slaughter the guards, and physically steal the box to take it back to our hidden underground lair... :)

No solution is 100% water-tight in every possible situation... but the goal here is to keep the script kiddies away, not to protect against an invasion force of US Army Rangers.

Compared to some of the online shop setups I've seen in the last 5 years (Storing everying in an Access database, that was stored IN the root directory of the website, or my other favorite... processing the order and then plain-text-emailing the CC# to the shop) any level of security would be better. The process outlined before is just one possible solution, but it's one that is not that complex, yet would (done properly) keep most folks far far away from your CC information... (Of course, you still have the inside job problem.. what happens if Joe Employee decides he'd like to sell some CC#s for quick profit and just grabs the secret keys and a export of your database?)... but again, it's all a matter of what ifs.. there's always a way around.. even if it involves blowing things up. ;)

Ahmad, here is a scenario. You use the term "hack into". What if the MySQL server is ONLY accessable via HTTPS, port 443.

443 is the only port traffic allowed in my firewall. No shell, no FTP, no sendmail/POP, and absolutely no remote database connects.

I've developed a nice way to update/access MySQL via HTTPS POSTED data.

Do you see Apache as an easy way to hack a server? Just curious.

Originally posted by driverdave
Ahmad, here is a scenario. You use the term "hack into". What if the MySQL server is ONLY accessable via HTTPS, port 443.

443 is the only port traffic allowed in my firewall. No shell, no FTP, no sendmail/POP, and absolutely no remote database connects.

I've developed a nice way to update/access MySQL via HTTPS POSTED data.

Do you see Apache as an easy way to hack a server? Just curious.

About a month ago, a vulnerability in Apache was discovered that gives the attaker root access to the machine. Another point to make is the software you are using to process the POST data and store them in the DB. There have been a very recent vulnerability in PHP too.

Originally posted by Shannon
There's always a better way, and nomatter what you do, armed with a couple tanks, some C4, and say, the army of some small country, we'll get your precious credit card numbers every time, even if we have to kidnap you at night, chop your finger off, and use it to get around the biometric scanner on your SQL box after we crash through the front door of your compound, slaughter the guards, and physically steal the box to take it back to our hidden underground lair... :)



very funny :) but I didn't mention physical access to the machine, because I'm not an expert at that. I believe it's a good idea to only give advise about things you understand, especially when it comes to other peoples reputation and money.


No solution is 100% water-tight in every possible situation... but the goal here is to keep the script kiddies away, not to protect against an invasion force of US Army Rangers.


It seems that what I talk about is of the weight of "an invasion force of US Army Rangers". I would expect that if you didn't understand anything of what I said :D


Compared to some of the online shop setups I've seen in the last 5 years (Storing everying in an Access database, that was stored IN the root directory of the website, or my other favorite... processing the order and then plain-text-emailing the CC# to the shop) any level of security would be better.


So your aim then is anything a little bit better the crappiest solution? No wonder then. :rolleyes:


The process outlined before is just one possible solution, but it's one that is not that complex, yet would (done properly) keep most folks far far away from your CC information... (Of course, you still have the inside job problem.. what happens if Joe Employee decides he'd like to sell some CC#s for quick profit and just grabs the secret keys and a export of your database?)... but again, it's all a matter of what ifs.. there's always a way around.. even if it involves blowing things up. ;)

Your solution sounds great for an untrained person. One of the things you must understand about security is that your security is as strong as the weakest point in the system. Anything extra will only give you a false feeling of security, and this is much worse than no security. Not to mention wasting your time and money.

* No matter what you do to prevent everybody from getting into the SQL server, where you keep the encryption key, if you then go ahead and put the key in your billing software, which is located on your webserver, then all you've done is worth nothing.

* You do not connect your SQL server directly to the Internet. Instead, you connect it to the Internet only through a vulnerable webserver. You implied and even sayd that it is not as bad if the webserver gets hacked. This gives you a false feeling of security.

* You encrypt the CC# twice, but then anybody that can have any kind of access to the data after the first encryption can have access to the encryption key as well. This will also give you a false feeling of security. The data is not actually encrypted twice, as the first encryption doens't count.

* Your SQL server is connected to your Internal network. Unless all your employees do not have access to the Internet, then anybody can use their machines to get access to the SQL server. This is probably the easiest way, as their machines are probably much more vulnerable than your webserver. They might even have more sensitive data than what's on your web server (i.e.: the 'really' secret key).

I'm sorry for that, you first sounded very interested in a secure system. You talked about things like smartcards, offline SQL server, closing all ports, .. etc. All of a sudden, it seems that you don't care about the CC#'s, and you are now talking about others that transmit them online in plain text.

Anyway, I didn't come here to bash you or anything like that. I thought you'd welcome an experts opinion. Even if you don't, I'm sure other people will find it useful. Besides, I've already provided an alternate solution, that is more secure, advanced, elegant and efficient.

One important step that can reduce your nightmare if you use php that is.

1. Encrypt all your php files using zend encoder..

2. Do NOT just assign your encrypt key to a variable.. Doing so allows anyone halfway familiar with PHP to pull the info by looking through the GLOBAL variable... Example

include("configfile.php.enc");
while (list ($key, $val) = each ($_GLOBAL)) {
echo "$key => $val<br />\n";
}


Oh look theres a variable called CRYPTKEY I wonder that that is..

3. So based on number 2, Do the following

function somesillyrandomname() {
return "THISISMYCRAZYKEY";
}


Now your variable is not floating around in global name space for a person to grab with a simple bit of php code...

While granted its not a perfect solution it will keep any scriptkiddies from getting your information.

Oh yea.. dont be stupid and do the following


$key = somesillyrandomname()
$cc = decryptusing($key)

You just put your key into namespace again.. DOH...
Instead

$cc = decryptusing(somesillyrandomname())

Hi cyberlot,

This has been discussed several times before. An encoder (be it for PHP, Perl, Python, Java, C, C++, C#) only encodes the source of the file. It doesn't encode any literal strings. So whenever you put a string between tow qoutes, anybody can probably find it in the file by some inspection.

Encoders are good to hiding your code, not for hiding MySQL passwords or encryption keys.

The best solution, as I said before, is to have seperate encryption and decryption keys. This way, if you want to publish your encryption key on your first page, fine :). Nobody can use it to get your CC#'s. As most of what you are doing only requires encryption (storing CC#'s, changing CC#'s), you do not need to have the decryption key anywhere on any machine on the world.

I don't know why would anybody consider any solution except for public/private key encryption. :confused:

So what is the best type of encrption to use then, that offer public/private keys.

Any suggestions for ASP?

Adam

Okay then... what are some public/private key encryption programs that you can recommend?

I'm not sure about ASP. You can check the following resource for more information:

http://www.gnupg.org/
http://www.pgp.com/index.php
http://www.pgpi.org/

For searching engines use: 'public key cryptography' with any other extra keywords you want, e.g.: 'ASP component'.

If you use php here is a good piece to read

http://www.zend.com/zend/tut/tutorial-brogdon.php

Oh and if you want to be really paranoid ( I have seen this done ).

Rename a bunch of popular commands.. Then hardlinke those commands to a script that shuts down the server right away..

Imagine the frustration of a hacker when he finally roots your box... Goes to take a look around..

ls -al
POOF box is shutdown right away.


I did something very simliar to this on my machine years ago ( pre-windows ) got tired of my sister messing with my box so I moved commands all around.

Originally posted by cyberlot
If you use php here is a good piece to read

http://www.zend.com/zend/tut/tutorial-brogdon.php

Great article cyberlot. Thanks :)

Originally posted by Ahmad


Great article cyberlot. Thanks :)


We use Mac computers to store our customer information on :)

Not creditcard info, but the rest.

wtf? :confused: on a webserver? your asking for it :laugh:

Originally posted by dreamrae.com
wtf? :confused: on a webserver? your asking for it :laugh:

Can I ask you a question?

What prevents a cracker from intercepting the CC# information from anywhere over the Internet? Any machien in the route between you and the client can be cracked and the cracker can get the CC#'s. Or he can't? Why can't he?

Anyway, what you really need to do is ask your questions in the "Technical and Security Issues" forum.

Thats what SSL is for.. It encrypts the data as its being transfered between your web browser and the server, Making it next to impossible to snatch..

I store all my details on a seperate computer that isnt linked to nothing, which makes it pretty safe :)

Cheers,

Originally posted by cyberlot
Thats what SSL is for.. It encrypts the data as its being transfered between your web browser and the server, Making it next to impossible to snatch..

Exactly. SSL's security is dependent on public/private key cryptography. You send your public key to the client and the client encrypt data and send it back to you. Nobody can use the data being transmitted, because only the webserver has the private key to decrypt it. The same thing from the server to the client.

If you can trust virtually any point on the Internet that is transmitting the data between you and your client with your public key and encrypted data, then you should trust your own server for these pieces of data.

Even if somebody can get into the server, he can't make use of the data.

The only way to get the data is using the private key, which you only need to supply during a transaction.

There is even a better way to achieve security, but it only works by coordinating this with your payment gateway (or third party payment processor). I just thought of this, and It's probably already implemented somewhere.

It could be the answer to allowing 3rd party CC processing companies their sellers to charge any previously authenticated card without allowing the sellers to store the CC# at all.

Hi,


Great Post but, I'm wondering if there's a decent way for a reseller who doesn't have access to the actual web server.

I'm just starting in the reselling biz and ... I'm evaluating perlbill and modernbill ... which look good but, I think I am still in a quandry regarding credit card storage.

Somebody suggested ... LinkPoint.com (http://www.linkpoint.com/)

Any thoughts?

:dunce:
The only stupid question is the one unasked.
Brainstem