Best practices for storing bank information in a d

2019-01-30 10:47发布

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.

标签: php mysql mcrypt
9条回答
成全新的幸福
2楼-- · 2019-01-30 10:59

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!

查看更多
乱世女痞
3楼-- · 2019-01-30 10:59

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.

查看更多
该账号已被封号
4楼-- · 2019-01-30 11:02

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.

查看更多
\"骚年 ilove
5楼-- · 2019-01-30 11:08

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.

查看更多
何必那么认真
6楼-- · 2019-01-30 11:14

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!

查看更多
Viruses.
7楼-- · 2019-01-30 11:14

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.

查看更多
登录 后发表回答