Title: Security Standards For Payment Processing? Post by: Kewde on January 18, 2019, 09:48:09 PM Hi,
I'm theorizing what the ideal patterns are for developing applications that deal with centralized payment processing. I've come up with the following list, please let me know if there is more to add or if you think something is wrong. There have been many hacks, which is often the fault of monolith systems without proper isolation and authentication. I haven't looked into topics such as cold storage, anomaly detection, rate limiting and would love to hear ideas. 1. Use microservice pattern Following the microservice pattern is a must. Payment processors must force interaction through an API. The sensitive payment processing code must have its own database with limited privileges (eg. INSERT, UPDATE, SELECT). Ask yourself whether deletes are necessary, I recommend not giving it that ability such that there is an audit trail after an incident.
2. Split the cryptocurrencies into their own microservices and containers A malicious insertion into the source of one cryptocurrency, should not affect any other cryptocurrency.
3. Process payments from a queue, not on-demand
4. Authentication for microservice X should not be valid for microservice Y Make clever use of authentication. I recommend using OpenID Connect JWT tokens that a cryptographically signed by the authentication microservice. JWTs should:
Then the user turns to the authentication microservice and ask its to include the hash(challenge + API function + API request) in the creation of the JWT token specific for the cryptocurrency microservice. 5. Optimize for security not for performance
0. Obvious notes
Title: Re: Security Standards For Payment Processing? Post by: Kewde on January 23, 2019, 03:29:14 AM It's worth mentioning that tracking addresses is a lot harder than one might suspect.
Let's go with these assumptions: * Deposit addresses are UNIQUE (generated by server) * Withdrawal addresses are NOT UNIQUE (generated by untrusted parties) What's the rational for not forcing non-uniqueness on the withdrawal addresses? * If all withdrawal addresses are forced to be unique, I could submit any withdrawal address and if it bounces, I know it's in the database. => Leaks database information. Okay so we don't force uniqueness. What are the pitfalls? * Tracking addresses becomes complex, our database now has to allow for multiple records of the same withdraw address. We build a primary key { user, withdraw_address } for each record. => deduct the balance before the withdrawal goes into the queue, and make sure that it targets the right user. What if an attacker attempts to use a deposit address as a withdrawal address? * This is a more interesting scenario, especially if you combine both deposit and withdrawal addresses in the same table. Let's take this simple table as our initial state.
Mallory uses the deposit address of Alice as a withdrawal address.
Alice does a new deposit and the payment handler has a flaw, it assumes the deposit addresses are unique (not true in a combined table!). Code: SELECT user FROM table WHERE (address = A) The correct way of getting the right user for the deposit address would be: Code: SELECT user FROM table WHERE (address = A AND type= DEPOSIT) In a combined table (storing both deposit and withdrawal addresses), the primary key is { user, type, address }. Long story short, do not store deposit addresses and withdrawal addresses in the same table in your database. The uniqueness deposit vs withdraw addresses does not hold, and they deserve their own tables. A single missing type check in a query can spell disaster. Title: Re: Security Standards For Payment Processing? Post by: monsterer2 on January 23, 2019, 08:43:26 AM On the subject of withdrawals. Don't allow instant withdrawal. Schedule it for once per day.
In addition, do auditing of withdrawals. So, if you have an exchange, for example, is the withdrawing user withdrawing more than they should be able to going by the sum of their deposit amount and total p/l? If so, block it. edit: Altcoins are always being updated by their creators; be vigilant about updating for hardforks, or you will end up with users depositing and trading deprecated coins. And, of course, never store private keys on a server connected to the internet. Title: Re: Security Standards For Payment Processing? Post by: xWolfx on January 23, 2019, 05:01:14 PM On the subject of withdrawals. Don't allow instant withdrawal. Schedule it for once per day. In addition, do auditing of withdrawals. So, if you have an exchange, for example, is the withdrawing user withdrawing more than they should be able to going by the sum of their deposit amount and total p/l? If so, block it. edit: Altcoins are always being updated by their creators; be vigilant about updating for hardforks, or you will end up with users depositing and trading deprecated coins. And, of course, never store private keys on a server connected to the internet. This is in fact really important considering security above anything else. But now we need to ask ourselves, security and a good degree of anonymity? Or security without the last one? Because being able to check who each person is ends up being really important from a security point of view but could be too much hassle if security is not so important so depends here. Also it's worth nothing that people buys IDs and Passport pictures online, i personally saw and they are not even paying that much and some people is more than willing to give those away carelessly creating another security issue, which makes me doubt about how effective this way of identification is. It's just another idea anyways with pros and cons. |