store credit cards for customers

I need to store credit card info for customers, but obviously I want it to be secure.

I don't really want to store them in my SQL Server, as if it was ever compromised that would be a big problem. If I encrypted the values in the DB, I would need the code to decrypt them in the webpage, and the website and sql server sit on the same machine, so an attack could give a hacker both items they would need to get the card numbers...

what I was thinking, was to store the credit card numbers in cookies on the customers local machine, but encrypt them using the password for their account (which is stored in my SQL Server)

so when they log in, the key would be available to decrypt the cookie and have the valid card number....

If that is not secure enough, I was thinking about doing that with half the card number, and the second half be stored in the database, and they would be put together at transaction time..

what do you guys think?

Quote:

---

Originally Posted by kleinma

I need to store credit card info for customers, but obviously I want it to be secure.

I don't really want to store them in my SQL Server, as if it was ever compromised that would be a big problem. If I encrypted the values in the DB, I would need the code to decrypt them in the webpage, and the website and sql server sit on the same machine, so an attack could give a hacker both items they would need to get the card numbers...

what I was thinking, was to store the credit card numbers in cookies on the customers local machine, but encrypt them using the password for their account (which is stored in my SQL Server)

so when they log in, the key would be available to decrypt the cookie and have the valid card number....


If that is not secure enough, I was thinking about doing that with half the card number, and the second half be stored in the database, and they would be put together at transaction time..

what do you guys think?

---

Its never a good idea to store CC card or Password in a Database. The usual practice is to store the Hash value of the CC card and store that hash value in the DB. Most site uses this technique and almost all site uses this to store password including vBulletin.

I personally use MD5 Has function to store Password or CC card information, this way even if the Database is compromised they will never be able to get the sensetive information.

I MD5 all passwords and the like. But you can't do a great deal with credit card information if all you have is a one way hash. Sort of defeats the purpose of storing it in the first place, no?

I like the cookies idea, but what if the end user clears the cookies or they expire? *scratches chin*

yeah i thought about that.... but can't you set cookies to not expire??? also if they delete them they have to enter it again... they would be informed its kept in a cookie....

if i did a reversable md5 hash on the CC, then i could encrypt it into the DB, and decrypt it when its pulled, but this could be a problem since i would also have to store the password used for the encryption on my website in the asp.net application... so if they comprismised the DB, they could also get the asp.net files, and have both sets of info they need to get the numbers....

i just want to cover my ass for when we start doing this.. i know its done on many sites.. so i know its very possible.. i also know some of these sites have gotten hacked in the past...

Quote:

---

Originally Posted by kleinma

yeah i thought about that.... but can't you set cookies to not expire??? also if they delete them they have to enter it again... they would be informed its kept in a cookie....

if i did a reversable md5 hash on the CC, then i could encrypt it into the DB, and decrypt it when its pulled, but this could be a problem since i would also have to store the password used for the encryption on my website in the asp.net application... so if they comprismised the DB, they could also get the asp.net files, and have both sets of info they need to get the numbers....

i just want to cover my ass for when we start doing this.. i know its done on many sites.. so i know its very possible.. i also know some of these sites have gotten hacked in the past...

---

Tom you are right if you use one way hash then you cant get the information back. To be honest there is no fool-proof way of storing CC card data safely if you have to read it back.

kleinma, I would strongly advise you against storing CC car info in the user's pc even though it might be encrypted. There are many risks, e.g user might be using Shared computer. Also some browser including IE blocks cookies so if thats the case you wont be able to save the cookie.

Do you have to store the Password? Are you passing it to a 3rd party gateway for verification? Why not store the other information apart from the actual number.

Read these article, might help you secure the data if you choose to store it.

http://www.seifried.org/security/cry...toring-cc.html
http://www.webmasterworld.com/forum22/3015.htm

I was just thinking why not use an encryption key which is derived from your Host e.g Host's HD Serial + Host IP + other Unique Config etc. I would write an COM object which will contain my Decryption routine this will generate the Unique Key from those elements I mentioned, this key will be Unique to this machine. This will reduce the risk of someone getting hold of decryption key, if the Host's security is compromised.

I know if the server is compromised they can decrypt it onsite but at least it will be harder to decrypt them offline. May be you should monitor all decryption attem on the server.

What technology are you using? If its ASP or ASP.Net then you can implement something similar using COM.

Just an idea from my top of my head, havent given much thought.

Hope this helps.

Danial

If you are going to store the password in the database use a good encryption method and require 128bit SSL.

I would encrypt the credit card number based on the plain text(or reversible cypher) password... store a hash of the users password in the database (for login) and then the credit card number could only be decripted if the client supplies the plain text password.

I would also never allow the user to view there credit card information (or atleast require a login even if they are currently logged in)

I would also encrypt the expiry date and security code (if it has it) as well as the type .... this would be a drag on performance.

I would also be careful about generating keys based on the hosts hardware because hardware fails and gets updated... you might endup, at the vary least, regenerating all your data from the old database -- if you were able to recover the key.

Quote:

---

Originally Posted by <ABX

If you are going to store the password in the database use a good encryption method and require 128bit SSL.

I would encrypt the credit card number based on the plain text(or reversible cypher) password... store a hash of the users password in the database (for login) and then the credit card number could only be decripted if the client supplies the plain text password.

I would also never allow the user to view there credit card information (or atleast require a login even if they are currently logged in)

I would also encrypt the expiry date and security code (if it has it) as well as the type .... this would be a drag on performance.

I would also be careful about generating keys based on the hosts hardware because hardware fails and gets updated... you might endup, at the vary least, regenerating all your data from the old database -- if you were able to recover the key.

---

That is a very good idea. I do agree that there are flaws in my idea, just didnt think enough about it. I like the idea about using user's plain text as the password. Sounds quite safe enough to me.

What I do is;

Store the first four or last four or both sets of numbers of the CC in the database. Then store the actual CC in a database seperate from the live server - i.e. on a server with no direct connection from the internet to it.

Show the user;
4502 xxxx xxxx 1234
or
xxxx xxxx xxxx 1234
or
4502 xxxx xxxx xxxx

And ask if they want to use that credit card (if I remember correctly that's how amazon does it?).
Then if they wish to proceed with a transaction, notify another web service or a human to continue processing, and take the actual c/c from the 2nd DB.

my problem is I only have 1 DB to work with for this particular thing.. so I can't take a 2 DB approach (which is obviously very secure from a storage standpoint...)

I will look at the suggestion from ABX and possible stored encrypted CC numbers using the users plain text password, but store the hashed password...

I assume I should use a 1 way hash right? like user entered password of "hello" hello is hashed to the database.... when they login again, you hash the password they enter and see if it matches the stored DB hash right? no need to convert the hash back to plain text...

one thing i thought of that is an issue, but I could just write code to deal with it i suppose, is if the user decides to change their password, I would need to then decrypt the CC numbers and re-encrypt them using the new password.. otherwise there would be problems...

upon thinking about this more, I don't know if it will work because I forgot that WE will also need access to their CC numbers, but we don't want their account passwords obviously....

but we will have automatic processing for some customers in which case we would need to have their decrypted CC number, and if their plain text password is the only way to get it, then that is no good...

hmmm any other ideas?

I also realized that your method has the following flaw:

if the customer forgets their password, there would be no way to get it from them except to reset it to a random generated password, in which case, the stored CC numbers would not be valid

Question. I f you compile you encryption code into a dll and the encryption keys are in the dll in an internal class, isn't this secure? I mean if the dll gets decompiled your have a problem, but that should not happen.

I use a data class for my user. The password is automatical encrypted and decrypted inside the property password that is based on a db field of password. So the only way to get the data is with the dll, otherwise it is encrypted. I would do the same for my CC and I actual do it for bank account information as well as passwords.

Now if someone has the dll, my security is breached but I trust my host not to let that happen. Because, well they would get sued.

Quote:

---

Originally Posted by kleinma

I will look at the suggestion from ABX and possible stored encrypted CC numbers using the users plain text password, but store the hashed password...

I assume I should use a 1 way hash right? like user entered password of "hello" hello is hashed to the database.... when they login again, you hash the password they enter and see if it matches the stored DB hash right? no need to convert the hash back to plain text...

---

Yes, i meant using a one way hash such as MD5 on the password.

Quote:

---

Originally Posted by kleinma

I also realized that your method has the following flaw:

if the customer forgets their password, there would be no way to get it from them except to reset it to a random generated password, in which case, the stored CC numbers would not be valid

---

I would want to require entry, so i would delete the credit card records upon deletion.

Yes this is may trouble the user, but i think the protection is worth requiring the reentry of the CC info.

Quote:

---

Originally Posted by kleinma

upon thinking about this more, I don't know if it will work because I forgot that WE will also need access to their CC numbers, but we don't want their account passwords obviously....

---

This way you could only process orders upon user request. For example:

If you had a checkout cart system. :

User logs in.
Adds thier items/services to cart.
Views totals/taxes/ect
Confirmation/Disclamier page --> By Entering your password here you give us permission to use the credit card information provided ....

then you use the password provided on the disclamer page for the transaction. (would not really matter if your printing or using online transaction)

Edit:

How are your transactions taking place?

Manual Printouts?
Automated Transactions?
Mixed?

Do your transactions take place right after? or are they queued, delayed, ect?

mixed... basically we need the ability to have the customer log into their account online and pay invoices, or order products, etc...

we also need the ability to process their cards here (without their request)

and what I mean by that is, we are a specialty software company, and some customers are on automatic billing, where there is a revision, they get set the software with a bill, others just get an order form.

the people who get the software with the bill, we would like to move that to, if your credit card is on file, it will be charged (this would of course be explained to the customer, as most request this method now anyway)

so its a mix... basically I would need to know the password used for the encryption...

now if I did what Magiaus said and store the password in a DLL, that would work (since all codebehind goes in the DLL) but how secure is THAT, i mean couldn't they technically get the DLL (if the server was hacked), and use the DLL to get the card numbers? or try to crack the DLL... i mean aren't a lot of things in .NET assemblies stored in plain text?

If they got the dll file any they knew anything about .net framework it would not take them long (if any time) to get the key and from there the credit card information.

--------------

Then i would suggest using pubic key encryption:

The asp.net application would know only the public key to store the credit card information in the database. this way even if your web application is compromised, all they can do is add/edit information.

But this has a drawback. Orders that are automatcially processed would have to be processed by another application that knows the private key. This application would need access to the sql transaction rescords (this could work via internet or internal network).

You would also now need an application to allow your manual data entery ppl to get the credit card information (this may have security issues).

If you are hosting this application yourself i would take extra caution to make sure that it is impossible(or nearly) for them to backtrack to the applications that know the private key.

yes it would be in the idl plain as day if disassembled. the only flaw is if they get the dll. I find that acceptable risk, but it's up to you and your people to make that call.

There is another option that isn't much better. The Registry. You could hide your key in the registry somewhere or a .sys file in the system32 dir or something. There are a lot of problems that could come from this though. Most things are going to have a flaw. You just have to find what fits for you.

ok well i will give you all the elements of what I have and if you can suggest the best course of action:

VB.NET app here that interfaces with SQL Server to handle our customer accounts

ASP.NET app on our hosted webserver that uses the same DLL as our VB.NET app to interface with the database (DLL has all the classes and everything and does all data access with SQL Server)

both apps need access to credit card numbers...

SQL Server sits on webserver. (SQL Server and webserver are 3rd party hosted)

there are only 1 other employee in the company here who would ever use this software. so security IN HOUSE is not of concern... security at the webhost is not of concern... major concern is just a hacker...

what if I created a DLL that handled the encryption, then used a dotfusicator on that DLL... so that if it was disassembled, it wouldn't be of any use anyway???

So i take it the public key encryption method above is out of the question.

Symmetric Encryption Method:

1) Generate a completely random key
2) Use this key to encrypt a hash of static user information (userid/username/firstname/lastname/ect.)
3) Use the ecrypted hash to then encrypt/decrypt the CC information

This way even if the attacker gets your private key not all is lost because they still have to figure out what type of hash you used, what information you used, ect.

This process is reversible if you still have the static user information.

Private Key Storage Options:

Compile it in an assembly:
-If you choose this method i would also encrypt the private key and decrypt at runtime. Do not make the decrypted result availible outside the assembly (duh :D).
-Assemblies can be decompiled, obfusication should be used.

Local Media:
-Like anything else, it can fail, be sure to backup the key.
-I would advise against hiding the keyfile in system directories because some windows 'repair' utilities remove foreign files. (but most should leave it alone, but you put yourself at the mercy of others judgement)
-Registry: The windows registry is full of misc entries and is one of the first places looked in for application settings, you would also need to set special permissions for aspnet_wp.exe to access the values.
-Web.Config, If its encrypted its not too bad, unless the attacker really knows .net. It's up to you, it would make deployment easier but as soon as they get access to that file they could get your public key

SmartCards:

Smart cards can provide a very secure way of generating, storing and using private keys.

-There are libraries availibible to .net.
-Cost, They would cost you about ~70 USD For the reader/writer + ~20-80 per card.

Not to compromise security, but what did you go with?

Credit card information is probably the #1 target for hackers and I'm not talking about Billy the 17 year old computer guru. Organized crime outfits in countries which thrive in payoffs to local officials are your number one concern.

If you work at a small software company, chances are you don't have someone to keep a continous eye on the transactions and the database itself. Its one thing for you store account information such as name and address and ordered products - but I would highly recommend using a third party vendor that specializes in storing the cc info. For a lot of small companies - you either require no automatic billing (which negates the need to store info - just process the card number real time over ssl allowing the info to exist only during the transaction), or if you do - contract out to a qualified and specialized company for handling this information. They have people and software tools that check for hacking attempts on a continuous basis.

Customers can still view their invoices, bills, payments - but updating their cc info or processing a charge should require your webserver to contact a third party server from a company that specializes in it.

In this manner - since the proprietary key or software protocol lives on your server - the hacker can't impersonate his computer as your server - because the ip address, and/or domain request wouldn't match. So then you're left with just making sure your web application is secure so it can't be forced to act on the hacker's behalf.

If you do decide to take on the responsiblity yourself - just know that your exposing your company to the possibility of lawsuits in the future. A good lawyer or worse Visa themselves could cost the company hundreds of thousands.

Bottom line : Since your requesting automatic rebill - contact it out to the third-party service , or if that's absolutely not possible - send the customer an email to pay their bill - which requires they visit the site,sign in and then re-enter their credit card number to process the transaction.

And if all that doesn't fly with your managers - allow the web application to only WRITE data to the table that stores the CC info. Then the hacker can only write bogus numbers - but can't retrieve what is in the table.

Customers that update their cc info don't need or care about their old credit card info - they just need to provide a new credit card number and expiration date. If you wish to provide some clue about which credit card the customer is using to the customer, simply display the card issuer's name. I have 3 credit cards - they are all from different issuers. Or like plenderj suggested, store the ccv number in a seperate table, so the web app can only read from that table - but only store that information and not the number itself.

When a customer purchases a product - the web app simply writes the customer id number into another table with the amount and purchase information (product, quantity, whatever).

Then on a nightly basis, have a seperate application that does not respond to internet requests except from the domain or ip of your online merchant provider( and definitely not from your web app server). This application only needs READ access to that table, spooling through the daily transaction requests your web app wrote in the table, and communicates with the merhcant service to process the day's transactions.

Maybe this is just me, but I would think using a Third party security measure that is widely used would lower security. The first thing that comes to mind are viruses that attack programs like Nortan first.... Seems an elite hacker would be more able to get through a system he/she knew about than one he/she didn't. The READ/WRITE seems like a good idea though.

Yes, a third party that handles storing cc info is more of a target, but they specialize in these things and have people and systems continously watching and checking the data and the requests. A hacker doesn't have much time after they infiltrate these type of systems - because there is a team on alert to the situation. If you handle it yourself, you may never even know a hacker stole information at the most once a day - if your company had such a policy in place to check the logs on a daily basis, which I'm guessing his won't.

Using a third-party, from a legal standpoint - they will have the resources to prove they made a best-faith effort to secure the data. Not having systems or live people overviewing the continous processing would probably not constitute best-faith in court. If I owned a small company, I would rather pay a measly transaction fee than be held accountable for losing 100's or thousands of credit card numbers to hackers.

Good point.

Also, I would only allow the customer to update their credit card information once a day at most (perhaps even once a week) - so a hacker cannot continously try bogus numbers.

And the web app and sql server SHOULD be on seperate servers.

When I worked at a Bank a few years back we actually used the CC info as a basis to setup an account for Online Banking. CC being Check Card in this case. We hosted our own servers and counted on our Servers being secure. I'm going to point out now that the people at the bank were not top notch programmers. They were good at the job they did but they weren't leading in the industry. The bank brought in an outside agent to secure the Servers. Firewalls and so on. We had no encryption, period. I imagine it is still that way. Complete faith in the SSL the Firewall and this one guy saying everything was secure....

I have to implement a credit card processing on a furniture site soon... but thankfully, there is no need to rebill the customer. All transactions will be live - and they will be required to re-fill their cc info every transaction. But that's a furniture store where people don't normally buy more than one thing a year.

So all I need to do really is just store perhaps the last 3 digits of their cc number - although I wonder if the last three digits are the most identifying part of the number or not... ?

I don't know how much this helps but cards have a 3 digit verification number now. I know Check Cards have this at least I assume Credit Cards do as well.

Storing credit card numbers is a horrible idea if you are not aware of what you are doing. Most companies can not dedicate the resources to handle the security aspects of things.

People, the managers don't understand, it is our job to inform them. You can only make is as secure as much as you know security. If you are asking this question here, you don't know it enough to implement this solution. 1,000 hackers have more knowledge than you, so be humble in this area.

Tell the managers that if you store credit cards, you immediately become a target to a whole new breed of hackers. This breed try to get credit card numbers to steal peoples identities. If even one is successful, your company is liable 100% if you did not do due diligence to keep the information comletely safe.

Outside companies that handle this employ everything they know to keep the card numbers safe. This is their FULL TIME JOB. They wouldn't be so big if they were not successful in doing this.

Give these links to your managers, this they will understand:
First, some insurance to cover what you are going to do:
http://www.hoyla.com/sec_c.html

http://www.aignetadvantage.com/bp/se...laims.examples

http://www.geeknewz.com/board/lofive...php/t1850.html

http://www.wcpo.com/news/2003/local/08/08/hacker.html

Have fun. I would NEVER put my name on some home grown solution involving credit cards unless EVERY aspect of security is covered. This includes full time monitoring. If you can't do this, contract it out.
Be careful.

Quote:

---

Originally Posted by nemaroller

I have to implement a credit card processing on a furniture site soon... but thankfully, there is no need to rebill the customer. All transactions will be live - and they will be required to re-fill their cc info every transaction. But that's a furniture store where people don't normally buy more than one thing a year.

So all I need to do really is just store perhaps the last 3 digits of their cc number - although I wonder if the last three digits are the most identifying part of the number or not... ?

---

The starting digits are common for each company they use a set. This is how CC Gen programs work. I don't remember the sets right now, but look at your visa does it start with 4668?

Hellswraith is right though, I've had people ask me many times to just throw around cc info and turned down the job for that reason.

There is a lot to think about. If your SQL Server resides on a seprate server has it been moved of the default port? If it's on the same server have you closed the port? Are your logs on? Are you tracking the IP of the request?(You know which Coffee Shop, Collage, or libray was the hacker at? Did he reroute his ip 36 or 37 times?) Are you sending a verify request to an e-mail address? Use an SSL.

Even better use an SSL, Frames and an ISAPI Companat. Ever seen a site with a URL of https://url.com/secure/cart.dll?orde...d&prod_id=guid

it's a lot of work.

Hellswraith the URL rewrite would cover a dll like this without the ISAPI.

Can you set a SELECT Trigger in SQL Server?