How to protect the money balance on the site from cheating?

Question

PHP

Good afternoon, the site plans to receive money for actions, games, etc.
There was a question about protection, how to protect the balance from if suddenly a hacker gets access to the database and inserts a fake value (calculates the balance for himself)
I thought to sign each md5 award, but copy the table to 2 databases, check the signature and check with the second when outputting bd. How secure can it be? or can you advise something please.

Answer 1

check everything on the server and don't trust any information from the user
i.e. the site itself is like a computer monitor, and all the most interesting happens on the server (such as a system unit that is next to the monitor)

Answer 2

Use RSA keys, each user has their own key pair. One (public) is transferred to the server, the other (private) remains with the user. When a transaction is made, for example, a purchase, then the information should be sent to the server:
Each transaction must be accompanied by a fingerprint of all these values, signed using the buyer's private key. On the server, this fingerprint must be verified using the same user's public key. The public key can be stored in the database. It's just for reference.
To complete a transaction (purchase), you need to check if there are enough funds on the balance of the user-buyer. To do this, you need to remove all transactions of the user-buyer from the database, check the fingerprint for each transaction and summarize those with the correct fingerprint.
Check transaction times. For each buyer, all transactions must be strictly chronological. It should not be that the purchase of N + 1 was BEFORE the purchase of N.
It takes a long time to calculate. To speed up the calculation of the balance, you can enter a special type of transaction "status at the beginning of the month". It must be performed by a third-party trusted server that has its own special key pair. Then the current balance = the last balance at the beginning of the month + all receipts - all payments. Computed much faster.
If an attacker breaks into the database, then making entries will be extremely difficult, because it will be impossible to forge a transaction fingerprint. Weak link - you can simply unload the database or table to a file and then drop the table or database and blackmail you with lost data. To prevent this, forbid users (not buyers, but those who connect to the database) to do DROP TABLE/DATABASE. Also make backups. Also keep a database mirror.
Everything that I described will be useless if an attacker replaces the source code of the payment server, since he can simply disable all fingerprint checks. Therefore, the payment server should not be scripted. That is, not PHP, node, Python, Ruby. It must be compilable code. With digital signature. The server must not run applications with a missing or incorrect digital signature.
But this does not prevent us from changing the list of trusted certificate authorities on the server in order to launch a fake application instead of the payment server. Therefore, on the DBMS side, it is necessary to implement a mechanism that prevents any application from connecting to the database. This application must have a special access mechanism. IP restriction, special headers, special session. So it's not MySQL and most likely not PostgreSQL.
Is there anything else to talk about, or is that enough?
Specialists from WebMoney, PayPal, Yandex.Money and online banks are now looking at my algorithm without hiding a smile. Hello to you all, friends!
Regarding the PHP implementation . Two servers making requests via AJAX will not make the server more reliable, because everything can be faked in the browser.
You want to prevent the user from accessing the server. There are a huge number of articles on the Internet on this topic. I'm afraid I can't remember the full list of access prevention tools. In any case, there are more methods of hacking than methods of protection in PHP.
Here is a list of ways to get into the server:
And here is a list of ways to reduce the likelihood of penetration and causing irreparable damage:
Server health
Access to servers
Internal Services
PHP Application

• Secure your site with SSL
  
• Use an additional payment password, limit the number of payment attempts with an incorrect password
  
• Use server side http cookies, short sessions with session key binding to client IP and UserAgent
  
• All queries to the database should be only using bindable parameters, no query concatenations with parameters
  
• Don't trust client-side data validation. Yes, they speed up the work, but they can be easily faked. Therefore, duplicate all checks in the code on the server.
  
• Do not trust user data: filter strings, cut off tags , shorten to acceptable length , convert all numbers to numbers XSS")
  
• All requests to the server must be accompanied by a security token ( https: //en.wikipedia.org/wiki/%D0%9C%D0%B5%D0%B6%D ... .ru/post/235247 and others for the phrase "CSRF" )
  
• Do not auto-redirect anywhere to the page specified in the request parameters - this is usually done in order to return to the place where the login form was called from after login
  
• I already wrote about the content of transactions, I don’t know which of these will be useful to you
  

Answer 3

The user should not have access to certain actions. This is a security issue. And your task is only a special case of this task. Therefore, this problem must be solved globally, and not within the framework of this task.
If it's simple - read what Curly Brace wrote to you.
Another question is how to protect yourself from a bot that can perform an action for which you charge money several times per second. But this is a different task and its solution will depend on your skills and application architecture.

Answer 4

If an attacker gains access to the server, then no other databases will help, because he will be able to get passwords and access keys to other databases/services. The only sure way is to keep hackers out of your server, monitor suspicious activity, and make regular backups.

Answer 5

GOD forbid you receive game (and not only!) business logic of a web application from a client (from a browser, etc.)!
1. All checkpoints - check on the server via socket/ajax.
2. The most important check is time stretch/compress: don't allow teleportation and matrix effects where they shouldn't be!
3. Validate ALL inputs before processing through regular expressions.

Answer 6

Next to the balance, store its hash (uid+balance+salt). Store the salt for the hash in the application code so that it is difficult to get it. Thus, without a deep study of the code, it will be difficult to understand which key and how the hash is formed. And if the code also compiles, then an almost ideal solution.