How is banking softwares used over the internet [closed]

Question

I'm developing a banking software using php and that will be used over the internet. What are some of the security steps I should take in db design, programming, hosting...? thanks.

Answer 1

This is probably not what you want to hear, but...

DO NOT DO THIS.

Security is a huge and complex field, and even big companies get it hideously wrong on a regular basis. Add this to the fact that you want to deal with financial information, and you've got a legal quagmire to wade through too. The policies and legislation alone involved in such a project is enough to fill several books.

I wouldn't attempt such a project myself. It's a huge undertaking and requires extensive technical and legal experience.

If you're really interested in security, spend some time reading questions and answers on here, and researching these topics until you feel comfortable with the concepts involved. Hopefully, then, you'll understand why we give this advice.

Answer 2

100% agree with polynomial. But a few more tips.

1. Don't use any third-party hosting/shared hosting/VPS/database. The sysadmins at the third-party hosting in principle have full access to all the data on that machine and are outside your ability to fully monitor. Can you ensure that they didn't alter the virtual machine running your application to change an integer representing their balance from $20 to $65556? You are going to need to have full-time staff to maintain these machines, and the redundant backups.

2. Don't use php; its a notoriously hard langague to program securely in, and is only used for web frontends. The web front-end of your banking application is the least of your worries. You need to worry about the backend that verifies data integrity of your system. E.g., a bank teller can't increase an accounts' balance with accepting checks/money that's validated at the end of the day; or if someone transfers money from account A to account B that account A always decreases by the same amount account B increases by, and there's no way for someone to get into the system and alter the database. Recognize the need to delay transfers, clear a check, accept a deposit, to detect and reverse fraud.

3. When you have that database system fully operational and intact, you can think about concocting a web frontend. Again, I wouldn't suggest php. Make sure your system is robust against SQL injection, CSRF, XSS, MITM attacks, uses end-to-end transport layer encryption with a valid certificate, doesn't store passwords (but strong key-strengthened salted hashes), possibly uses 2-factor authentication. Do all calculations/transactions server-side; do not trust user input. Send notifications to a user through a third channel (email/phone call) every time a transfer is made; bill is paid; etc. Make sure your application has full audit logs in a convenient to analyze format and has paid staff looking for attack patterns doing their best to prevent them.

4. Then hire one or more security consultants to audit your software before going live, and do not go live until there's been one full security audit by experts before going live.

5. Be up to date on the relevant banking laws and your potential liability for screwing this up in your area.

6. Background checks on all personal with any heightened privileges.

PS: I have no experience designing any banking software like this, and this is just the tip of the iceberg.