Best practices for storing bank information in a database

Question

Summary of answers:
Don't do it. The legal and financial implications will be disastrous. Look for established third party solutions or hire an expert. Never store any sensitive information on a shared server. Research for the most appropriate encryption mechanism.

I am buiding a website for a customer that needs to store his clients' bank info (routing + account number) in the db for direct deposit. Here are some specifics:

1) The website will initially be on a shared hosting server (this is my first concern).
2) I am using PHP/MySQL.
3) I plan on using mcrypt.
4) The key will be located outside the web root.

Please let me know your thoughts. If possible, please provide me with some resources on ACH processing.

Thanks!

EDIT: I expected such response as I am terrified of security issues out there also. I have expressed my concern to my customer and this will be a good support.

EDIT 2: Will walk away from this. Was not happy with the idea in the first place! Will investigate PayPal's Mass Payment API.

Elly

Honestly though, there are some things you should just walk away from and this is one of them. I don't know how you could ever provide sufficient security on a shared web host to store personal banking information. – Goosy

There is also a large concern with liability. If the data is compromised and you were the one who built the system, there is a chance it can come back to you. I'd talk to a lawyer about this stuff. – Confluent

I'm seeing...a future headline...something about 1000's of consumers banking info lost... – Uptotheminute

this is one job I would walk away from. Too much liability. Even if you get by without getting sued, you'll still have the stigma of having written a system that got comprimised. – Anaglyph

What bank? What hosting service? ;) – Bartolomeo

Dude, I wouldn't even consider putting information this sensitive on a shared server. No way, no how. – Fragmentation

Answer 1

I think you can solve this problem without storing any bank information yourself through using something like Paypal's Mass Payment API. That way, your client can pay people, and PayPal stores all the information so you don't have to.

If you want to read about all of the steps you need to take to even have a remote possiblity of securing your client's sensitive financial data, google 'PCI Compliance'

If you're not deathly afraid of storing financial data online, you're horribly naive.

Volvox

Oh how I wish I could upvote this more than once: 'If you're not deathly afraid of storing financial data online, you're horribly naive.' – Goosy

To be fair to the OP - he was not being naive. He was asking it from the tone of the question definitely sounded like he was not really into it. – Equivocation

Agree with Tim. It sounds like the OP knew it was a bad idea, such a risky thing to do. – Arse

Yeah, looks like the OP was looking for good arguments against doing it. And this was a good answer. – Disciplinary

As the OP is afraid to store financial info online, I'd say he's not horribly naive, at least not in this case. :) I didn't mean to call the OP names, rather to help him, but the truth of my statement stands. :) – Volvox

Guys, I was not offended one bit! I honestly expected such a barrage of answers. I knew the general answer from the beginning. The great thing is getting nuggets of valuable info from within the responses. – Elly

I know this is a old topic, but does not PCI DSS stands for "Payment Card Industry Data Security Standard"? What does PCI has to do with bank account information? I still agree with everything else though, but felt, for the sake of Google's first search result page, that this should be said! – Miseno

I agree with @Edu - PCI relates to storing card information, not bank account details. – Yettayetti

Answer 2

1) The website will initially be on a shared hosting server (this is my first concern). --REALLY BAD. Not having absolute administrative control over the server, and be able to keep other people out is a really big problem.

I would be really concerned that you're directly accessing the database from the front end web server. That's a big no-no with financial data.

Even if you have the strongest encryption algorithm ever, what's to prevent someone from hijacking your system and using it to decrypt the data for them. They won't need the key, they'll just need your application to do the work for them. This is assuming you're using a single key to encrypt and decrypt the data or you are retrieving the data from the db to show to the users of the system.

Ok here's the thing. If you have to ask these questions, you don't have the technical expertise to do this correctly. I'm not trying to sound mean, it's just a fact. I would go work with a group of seasoned people who do this professionaly first. There will be a lot of things that aren't mentioned here that will need to be taken into consideration. there' a lot of stuff about security that isn't written down per se. Things that you won't pick up on from reading a book. This is a really hard thing to build, becuase there are big rewards to people who break into financial systems.

Anaglyph

AMEN!! and so that I have ten characters: AMEN AGAIN!! – Goosy

So then how does one store user banking details? I would say that it is a fairly common requirement in today's world. Telling the OP that he needs to be a uber security specialist isn't very helpful. Most people are most certainly not. So how would your standard developer go about storing such details? – Quiteris

@Zapnologica, your correct some more direction would be useful. But Kevin is on point. If you're asking these questions, you are not going to produce a result that wins for customer, user, and developer. You should either be asking WHO can we get to consult on this implementation with a verifiable expertise, or HOW can we work with our payment/ACH processor to resolve this in a manner that safely and securely stores the data. Let's just remember that Home Depot, Target, and numerous others have been burned... to the tune of millions for not protecting this type of data enough. – Distributive

Answer 3

Don't do it.

Bu, if you have to, use public/private key crypto. Store and use only the public key to encrypt the data going into the database. Store the private key in a secure location (meaning: not the hosted server, but a "secure" local machine with appropriate access controls). When necessary, download the data to the local machine, use the private key to decrypt it, and away you go.

But seriously, find a way to avoid doing this if you possibly can.

Ducky

Answer 4

Talk to a lawyer about your potential liabilities before continuing. Having personal banking data stored on a shared-hosting server has danger written all over it. You have no control over who can ultimately get their hands on the data.

Of additional concern is it's not your customer's data, it's your customer's client's data! You might be able to make an agreement with your customer to indemnify you, but not when their clients are involved. Once data is compromised, they'll turn right back to you with clients breathing down their neck in tow!

Germinant

Answer 5

For banking info, your server should be in their control not shared.

Also, mcrypt isn't very secure. I know it's built in but I would suggest something that isn't so hackable such as RSA. If someone does get a hold of the information, they shouldn't be able to hack it without a private key.

Confluent

Answer 6

I was facing a similar situation like you, and solved it this way.

1. Since you will not be doing ACH processing, find out if the ACH processing API has the ability to create a customer.
2. If yes, this customer object, will normally include account number, routing number, etc, and store the token in your database. (So when the user gives his info, you pass it straight to your ACH processor over HTTPS, and save the token).
3. Whenever you have to debit their account, pass this token to the processor, and that's it!!

This way, you are not saving any account and routing numbers on your database, and even if someone hacks the DB, they just see token's, which is pretty useless - they can't do anything with it, as it is ACH processor specific.

I've done similar for credit cards using Stripe.

Good luck!

Cupro

But a hacker could use the Stripe API to request the account data with the tokens, or am I wrong? – Lilililia

Answer 7

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

Dedicated servers can be had for between $79-$99 a month, if that's not affordable, I really would wonder why they're processing bank information to begin with. The preferred way would be to have the database seperate from the web box in this instance as well. Preferably with some firewalls and other protection between them (that is, 2 firewalls, one in front of the web server, and one between the web server and the database).

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

Also, please tell me the name of the site so I never sign up and put my banking info on it!!! :)

Also, make sure you have errors and ommission insurance before going forward with shared hosting.

Latini

Answer 8

You don't have experience in this area, and you can't even find cans of worms this big at a warehouse club. This is a case in which your customer needs to hire a domain expert; if you're interested in doing this kind of work in the future, try to work very closely with the expert and absorb as much knowledge as you can.

Meaganmeager

Answer 9

I think everybody here has announced their distaste of the situation enough, so I will just drop a hint on another problem when doing any kind of crypto (which we will agree is necessary):

The data has to be encrypted somewhere!

If you do it on the server, well a compromised server will just do your encryption and pass them on w/o encrypting them.

If you do it on the client, this is a bit more secure, but still leaves the door wide open if someone has access to your server: They can in theory simply open a XSS hole (i.e. insert a remote script into your page...) that sends a copy to their box before encrypting...

In the end: If you really consider doing this on a server that might not be 110% secure, WALK AWAY.

Abelabelard