php 在数据库中存储银行信息的最佳实践

Best practices for storing bank information in a database

提问by pistolshrimp

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.

1) 该网站最初将位于共享托管服务器上（这是我首先关心的问题）。
2) 我正在使用 PHP/MySQL。
3) 我打算使用 mcrypt。
4) 密钥将位于 Web 根目录之外。

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

请让我知道你的想法。如果可能，请向我提供一些有关 ACH 处理的资源。

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.

编辑 2：将远离此。一开始对这个想法并不满意！将调查 PayPal 的 Mass Payment API。

回答by Cameron Pope

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.

我认为您可以通过使用诸如Paypal's Mass Payment API 之类的东西来解决这个问题，而无需自己存储任何银行信息。这样，您的客户就可以向人们付款，而 PayPal 会存储所有信息，因此您不必这样做。

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'

如果您想了解甚至远程保护客户敏感财务数据所需采取的所有步骤，请搜索“ PCI 合规性”

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

如果您不是非常害怕在线存储财务数据，那您就太天真了。

回答by kemiller2002

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.

1) 该网站最初将位于共享托管服务器上（这是我首先关心的问题）。 - 特别糟糕。对服务器没有绝对的管理控制权，并且能够将其他人拒之门外是一个非常大的问题。

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.

我真的很担心您直接从前端 Web 服务器访问数据库。这是财务数据的一大禁忌。

Even if you have the strongest encryption algorithm ever, what's to prevent someone from hiHymaning 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.

好的，事情就是这样。如果您必须提出这些问题，则说明您没有正确执行此操作的技术专长。我不是想听起来刻薄，这只是一个事实。我会和一群经验丰富的人一起工作，他们首先做这方面的专业工作。将有很多这里没有提到的事情需要考虑。有很多关于安全性的内容本身并没有写下来。你不会从阅读一本书中学到的东西。这是一件非常困难的事情，因为闯入金融系统的人会得到丰厚的回报。

回答by Andrew Barnett

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.

但说真的，如果可能的话，想办法避免这样做。

回答by lc.

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'sdata! 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!

另一个令人担忧的是，这不是您客户的数据，而是您客户的客户数据！您或许可以与您的客户达成协议以对您进行赔偿，但在涉及他们的客户时则不行。一旦数据受到威胁，他们会立即回到您身边，客户会垂头丧气！

回答by Paulo

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.

此外，mcrypt 不是很安全。我知道它是内置的，但我会建议一些不太容易破解的东西，例如 RSA。如果有人确实掌握了信息，那么他们应该无法在没有私钥的情况下破解它。

回答by Sam Schutte

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).

专用服务器的价格在每月 79 美元到 99 美元之间，如果负担不起，我真的很想知道他们为什么要开始处理银行信息。在这种情况下，首选的方法是将数据库与 Web 框分开。最好在它们之间设置一些防火墙和其他保护（即 2 个防火墙，一个在 Web 服务器前面，一个在 Web 服务器和数据库之间）。

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?

但任何事情都比使用共享主机更好。我的意思是，您可以直接连接到 SQL 服务器并查看所有可用的数据库 - 以最少的黑客攻击直接进入有多容易？

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.

此外，在继续使用共享主机之前，请确保您有错误和遗漏保险。

回答by nithinreddy

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!!

1. 由于您不会进行 ACH 处理，因此请了解 ACH 处理 API 是否具有创建客户的能力。
2. 如果是，则此客户对象通常会包含帐号、路由号码等，并将令牌存储在您的数据库中。（因此，当用户提供他的信息时，您可以通过 HTTPS 将其直接传递给您的 ACH 处理器，并保存令牌）。
3. 每当您必须从他们的帐户中扣款时，将此令牌传递给处理器，就是这样！！

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.

这样，您就不会在数据库中保存任何帐户和路由号码，即使有人入侵了数据库，他们也只会看到令牌，这是非常无用的 - 他们无法使用它做任何事情，因为它是特定于 ACH 处理器的。

I've done similar for credit cards using Stripe.

我对使用 Stripe 的信用卡做了类似的处理。

Good luck!

祝你好运！

回答by Adam Jaskiewicz

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.

你没有这方面的经验，你甚至在仓库俱乐部找不到这么大的蠕虫罐头。在这种情况下，您的客户需要聘请领域专家；如果您将来有兴趣从事此类工作，请尝试与专家密切合作，并尽可能多地吸收知识。

回答by gha.st

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...

如果您在客户端执行此操作，这会更安全一些，但是如果有人可以访问您的服务器，仍然会敞开大门：理论上他们可以简单地打开一个 XSS 漏洞（即在您的页面中插入一个远程脚本.. .) 在加密之前将副本发送到他们的盒子...

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

最后：如果您真的考虑在可能不是 110% 安全的服务器上执行此操作，请走开。