Recommendations for storing banking information in a database

Question

Summary of responses:
Do not do this. Legal and financial implications will be disastrous. Look for installed third-party solutions or hire an expert. Never store sensitive information on a shared server. Research for the most suitable encryption mechanism.

I am creating a website for a client who needs to store his client’s banking information (route + account number) in db for direct deposit. Here are some features:

1) First, the website will be hosted on a shared hosting server (this is my first problem).
2) I am using PHP / MySQL.
3) I plan to use mcrypt.
4) The key will be located outside the root of the website.

Please let me know your thoughts. If possible, provide me some resources for ACH handling.

Thank!

EDIT: I expected such an answer as I am also afraid of security issues. I expressed my concern to my client, and this will be good support.

EDIT 2: Get away from this. At first this idea was unhappy! Explore the PayPal Mass Payment API.

Answer 1

I think that you can solve this problem without saving any banking information yourself, using something like the Paypal Mass Payment API . Thus, your client can pay people, and PayPal stores all the information, so you do not need to.

If you want to read about all the steps you need to take to be able to remotely access your client’s sensitive financial data, google PCI Compliance

If you are not mortally afraid to store financial data on the Internet, you are terribly naive.

Answer 2

1) First, the website will be hosted on a shared hosting server (this is my first problem). - REALLY BAD. Not having absolute administrative control over the server and being able to restrain other people, this is really a big problem.

I would be very concerned that you are accessing the database directly from a web server with an interface. This is a big no-no with financial data.

Even if you have the strongest encryption algorithm ever to prevent someone from hijacking your system and using it to decrypt data for them. They don’t need a key, they just need your application to do the work for them. It is assumed that you use one key to encrypt and decrypt data, or you extract data from a database for display to users of the system.

Ok, here's the thing. If you must ask these questions, you do not have the technical expertise to do this correctly. I'm not trying to sound mean, it's just a fact. I would go to work with a group of experienced people who first deal with this professional. There will be many things that are not mentioned here that need to be taken into account. There are many things about security that are not written down by themselves. Things you won’t get from reading a book. It is very difficult to build, because there are great rewards for people who break into financial systems.

Answer 3

Do not do this.

Bu, if you need to, use public / private key cryptography. Store and use only the public key to encrypt data entering the database. Keep the secret key in a safe place (which means: not a hosted server, but a "secure" local computer with appropriate access controls). If necessary, upload the data to the local computer, use the private key to decrypt it, and release it.

But seriously, find a way to avoid this, if possible.

Answer 4

Talk to your lawyer about your potential obligations before continuing. The presence of personal banking data stored on a server with shared hosting carries all the danger. You cannot control who can ultimately receive the data.

Of particular concern is that this is not your customer data, this is the data of your customer client! You may be able to negotiate with your client for damages, but not when their clients are involved. As soon as the data is compromised, they will return to you with customers breathing their neck in tow!

Answer 5

For banking information, your server must be under their control.

In addition, mcrypt is not very secure. I know that it is built-in, but I would suggest something that is not as hacked as RSA. If someone receives information, they cannot crack it without a private key.

Answer 6

I agree with the rest - this is a very bad idea.

Dedicated servers can range from $ 79 to $ 99 per month, if this is not available, I really wonder why they process banking information to begin with. The preferred way would be to have the database separate from the web box in this case. Preferably, with some firewalls and other protection between them (i.e., 2 firewalls, one in front of the web server and one between the web server and the database).

But nothing is better than using shared hosting. I mean, you can connect directly to the SQL server and see all the available databases - how easy would it be to go directly with minimal hacking?

In addition, please tell me the name of the site so that I never subscribe or put my banking information on it !!! :)

Also, make sure you have errors and omissions before you go ahead with shared hosting.

Answer 7

I came across a similar situation similar to you and solved it that way.

• Since you will not handle ACH, find out if the ACH processing API has the ability to create a client.
• If so, this customer object usually includes an account number, route number, etc. and stores the token in your database. (So, when the user gives his information, you transfer it directly to your ACH processor via HTTPS and save the token).
• Whenever you have to debit your account, pass this token to the processor and this!

Thus, you do not save account numbers and routes in your database, and even if someone breaks into the database, they just see a token that is pretty useless - they can do nothing about it, since this is ACH specific to the processor.

I did the same for credit cards using Stripe.

Good luck

Answer 8

You have no experience in this area, and you cannot even find banks of worms of this large in a warehouse club. This is the case when your client must hire a domain expert; if you are interested in doing such work in the future, try to work very closely with an expert and absorb as much knowledge as possible.

Answer 9

I think that everyone here has expressed their aversion to the situation enough, so I’ll just throw a hint at another problem when executing any cryptographic code (which we will agree is necessary):

Data must be encrypted somewhere!

If you do this on a server, a well-hacked server will just do your encryption and pass them without encryption.

If you do this on the client, it is a little safer, but still leaves the door open if someone has access to your server: they can theoretically just open the XSS hole (i.e. paste the remote script into your page .. .), which sends a copy to its folder before encryption ...

In the end: if you really think you are doing this on a server that cannot be 110% secure, WALK AWAY .