Best way to store data like credit card and social security numbers?

Hi all,

I was wondering what the best way is to store valuable data like these. Would a https connection and a mysql db be enough???

Any tips, suggestions


1 Like

The best method is not to store them. :slight_smile: But if you must then you need to some encryption on the numbers in the database just incase you ever get hacked.

Don’t store them.


hmm, if you not store how would you know who is who???What kind of process does one follow?

And indeed I am concerned about being hacked, but I am trying to figure out the process of dealing with valuable info.

Use a third-party processor like paypal.


No, https won’t be enough. I think that it’s even against the law in US to simply store cc numbers in db without any kind of encryption.

ITs not against the law but the CC comapnies REALLY frown on it… if you HAVE to store them (still not a good idea) you have got to use some serious encryption algorythmns to protect them, but even that cant guarantee your safety…

If you have been watching the news this week that CC processor that lost the 40 million cc numbers was storing cc numbers “for research” and ALL the CC Companies came right out and said it is against all their policies to store them!

I would also HIGHLY recommend ANY other db besides MySQL … its security is next to non existent… Whenever I do anything of this nature its Postgresql or Oracle…

whatever you do BE CAREFUL … if someone hacks your db YOU could be liable for any damage thats done!

Does anyone know what the laws are regarding this? Could you be sued if someone hacks your DB and gets your customers’ info? I’d imagine it’s possible. Either way, I don’t think I’d be able to sleep at night knowing that my customers’ personal financial info is sitting in my mysql DB. Let some other company deal with the headaches.

Only do this unless you are insured for insanely much money. It’s a HUGE risk. If you store CC numbers, you instantly turn your eCommerce store into a goldmine for hackers, and you can bet that hacking efforts towards your site will skyrocket. Only do it if you REALLY know your stuff.

Consider Amazon - from what I understand, they have a computer (or computers) they call the cc motel – the numbers check in, they don’t check out :).

It’s connected solely via a serial cable to the rest of their system, which makes it extremely feasible to do a careful security audit of the interface.

When they get a number, they send it over to the ccmotel, along with a unique identifier. They then store the unique ID, and send that ID over to the CCmotel whenever the card needs to be authorized/charged.

Hi, if you need personalization, implement registration process with user name and password

I also agree with others that storing both CCN & SSN is not necessary and potentially harmful approach even if you going to store them as MD5 hashes in your database :slight_smile:

still reading the theory before I start this project.

Lesson learned #1: I will not store Credit Card info

Maybe I should add the following info:

  • for this project only 50-100 people would know about it and are registered. (It is not a webshop)
  • they are all around the world
  • for my reward program I need personal (financial) info like VARStatement, Passport copy, bank info (like, International Bank Account Number)

Gonna leave out the CC info.

Would storage in a mysql db be doable and which encryption options do I have??

More tips, suggestion??

btw: about the law, which law is applicable? The law of the country where your server/database resist or your client’s country?

  • for my reward program I need personal (financial) info like VARStatement, Passport copy, bank info (like, International Bank Account Number)

One of the ways is to let users enter this information every time, so as a site owner you will be not responisble for this information’ privacy). All popular browsers such as MSIE or Mozilla support autocomplete for web forms feature

Would storage in a mysql db be doable and which encryption options do I have??

Check Best way to encrypt/decrypt sensitive information thread

To store this kind of data you should use encription algorithms. it is safe from attackers. There are encription algorithms which takes anyone to break them more than the life of this universe. Nowadays almost all data is stored in encripted form. Ex. PGP, RSA

I’m not so sure that there are such algorithms. I think RSA, PGP, DES, AES can be broekn within a year or less, depending on how much the information is worth. Then there are problems with storage of keys, if you store your key in a plain text file, then the best cipher is worthless.

As for the dataprotection laws: The applicable laws are laws of the country where the server is located. But you should state in your privacy policy what data you store and who has access to it and how is it used.

And do you need the data to be on the server, or do you need it only for your records internally. If the data doesn’t need to be on the server which is very probable, then I suggest moving it to secure computers in your office using a secure channel instead of storing it.

Yes, assuming the hacker doesn’t get the key, which they very possibly do if they get into your system. Encryption algorithms are good, but does not really add all that much storage security in my opinion. Encryption is a security technology mainly useful for transfer of data. For storage, it’s not as useful, since if the attacker accesses the server, he is very likely to get the key as well. Of course you should encrypt the stuff, but don’t be fooled into thinking it’s secure if it is encrypted.

What you REALLY need to have your credit card numbers on a separate server, a “amazon cc motel” if you will, not accessiable from the internet, but only from the internal network. It must also be very difficult to mass-access the cc database contained on the cc motel, even if you have the user database in hand.

I thought it was only illegal to store CCV and not credit card number.

It’s not illegal to store CC numbers, but if you lose them, you could probably (just guessing) be responsible for damages. Needless to say, the lost goodwill of losing thousands of credit card numbers is probably a lot worse for your business.

Envisioning the technology behind a credit card motel…

I picture an network-internal SSL-encrypted web service with just a few simple methods. All ports locked down except the necessary ones, and accepts only connections from the web server.

It only has three methods:

A. Method to retrieve an array of the first 4 and last 4 digits, expiry and card holder name of all the credit card numbers associated with an account, along with the Primary Keys for the credit cards. This method accepts the username of the user and a password*.

  • = Note that both the ccmotel db or the primary user database saves passwords as one-way hashes. As such, the user MUST input his password every time the above method is called. I.e. if a hacker gains access to the primary user database, he cannot (effectively**) use the hashes to access the cc motel, as it requires the unhashed password to work.

** Theoretically, you can brute-force one-way hashed passwords provided you know the algorithm used to hash them. However, this is a very computer-intensive process, and only feasiable to do for a password or two, not on an entire database.

B. Method to save credit card number to database. Takes password, cc number, expiry, card holder name, username.

C. Method to Charge Credit card.
Paramaters needed: Username, Password, CC number Primary Key*

  • = Note Primary Key, as retrieved through method A, NOT the cc number itself.

here is another option, from my post in the related thread in the mysql forum…

I was forced a while back to hold CC numbers on a server for a temporary amount of time (usually no more than a day) because the client had a set method for processing credit card orders.

I encrypted the numbers twice, once using mcrypt, and then again putting it into a hex string. The hex string came out looking like an MD5 character set (but was longer than 32bits) and was only recoverable if you knew the way it was turned into hex and if you had both of the IVs needed to get it out of mcrypt (one of which itself was encrypted). I was impressed with the way we did it but was still leary about keeping numbers around.

The best way is to do something like Mattias suggested. Store the CC numbers in a machine that is not connected to the internet and can only receive communication from a certain program and just holds and ID and the CC number.