Securing online services

To accept credit card payments online, you must perform the following tasks:

1. Obtain a merchant account with a bank
2. Build a database and online ordering system that can store credit card details
3. Ensure it is secured to the level specified by the PCI DSS (Payment Card Industry Data Security Standards)
4. Handle inspections by PCI auditors
5. Be prepared to handle chargebacks, potentially large volumes of them depending on the type of business

A chargeback occurs when the owner of a credit card disputes a transaction, typically because either they believe you did not deliver satisfactorily, or because the card details were stolen and used by a card fraudster. If a chargeback occurs, the credit card company will take back the money and also fine you. If too many of your transactions result in chargebacks, you will lose the ability to accept credit card transactions and most likely your online business with it.

As you may have noticed, whilst happy customers are somewhat under your control in aggregate, you have no control over how many credit card numbers are stolen. For this reason credit-card accepting merchants typically have large and sophisticated fraud control measures in place, involving dedicated risk operations staff, machine learning, JavaScript browser fingerprinting and so on. The goal being to spot repeat fraudsters and deny their transactions. Too many false positives and legitimate customers who want to pay for your product cannot, limiting your market. Too many false negatives and you can lose significant money to chargebacks, which may arrive weeks or months after the product or service has been delivered.

Unsurprisingly, many merchants choose to outsource this arduous process to a third party payment gateway like PayPal, Google Checkout and so on or a third party fraud prevention like FraudLabs Pro, Signifyd and so on. However all these services add their own policies, fees and often do not provide any guarantees of chargeback protection.

Storing money in an internet accessible bank account is convenient, but how safe it is depends very heavily on the type and quality of security measures put in place by your bank. A good online banking system looks like this:

1. To log in, it requires you to input a code into a dedicated hardware device and then type back the response.
2. To wire money, it requires you to input a fragment of the destination account number into a dedicated hardware device and then type back the response. Typically this is only required the first time you send money to an account. After that repeat transactions will be considered OK.
3. It uses SSL.
4. The bank will not issue new hardware or other credentials based purely on a phone conversation and a few personal trivia checks.
5. The bank may also perform manual inspection of unusual transactions and call you to verify them.

With such a setup the rates of fraudulent bank wires are low and so bank transfers tend to be hard to reverse, so merchants are also protected. This setup describes many banks around the world, especially in the European SEPA zone. Unfortunately some banks, particularly American banks, often look like this:

1. To log in you have to provide a password and something vaguely password-ish like a secret question
2. There are no dedicated hardware devices used
3. Security may be entirely heuristic
4. Though Fedwire bank wires are not reversible, banks can still return funds that were received such as when the transfer was the result of phishing, for instance.
5. Whilst consumer accounts may have some liability protection, business accounts do not

Because the security mechanisms in place are entirely controlled by your bank, if yours is unacceptable your only choice is to find another bank. If all banks serving your local market are the same, you're out of luck. Even if your bank has good security, accepting payments from a bank that does not can entail significant risk.

Server hacks have resulted in the loss of tens of thousands of Bitcoins. Any internet-connected computer that has liquid access to data worth hundreds of thousands of dollars will come under sophisticated and sustained attack, but there are some simple techniques you can use to reduce your risk.

• For merchants who need to automatically accept payments online but not make them, use an encrypted wallet that does not have the password on the server. To receive a payment all you need is a public key (for better privacy most merchants use one fresh key per user or transaction). The public key alone does not allow you to spend the money. By creating a wallet with plenty of keys on your own local computer and then uploading the encrypted version to the server, you ensure that whilst the server can accept payments only your own computer can make them, even though they share the same balance. Thus hacking the server doesn't allow any financial gain. Of course you must still ensure your local computer is secured.
• Some organizations need to be able to automatically send money as well as receive it. Examples include trading platforms and mining pools. These typically use cold storage as much as possible, where only the minimum balance necessary to handle withdrawls is on the server. The rest is sent to a separate wallet which is kept away from internet connected computers. Because a wallet can receive coins without it being online, profit can be moved from the server to cold storage without risking the cold money. If an unusually large withdrawal takes place the transaction can be placed on hold until a human operator has time to reach the cold wallet and send money from it to the live site. This limits your losses to the size of your hot wallet in the case of a server breach.
• Avoid managed server hosting. During 2012 several high profile breaches were caused not by lax security on the part of the site operators themselves but rather the companies providing the servers. Many datacenter operators, even large well known ones, are not equipped to handle sensitive data regardless of what assurances they may provide. They can be vulnerable to hacking and social engineering themselves. Instead, purchase your own server(s) and rent a cage / network connection from a local datacenter that you can visit in person. For added security, either disable remote access entirely or ensure only connections from your home IP ranges are allowed. Make sure the datacenter operator won't provide remote access on request without some pre-agreed security protocol being followed, like a callback.
• Consider implementing a supervisor system. In this scheme, the site gives its users multi-signature addresses for sending payments. The money received requires a signature by both the website and an independent supervisor computer. The job of the supervisor is to analyze the stream of payment requests from the other server and try to spot anomalies. If a payment request looks OK then it will be signed. If it looks iffy a human will be called for further attention. The supervisor can be made a lot more secure than the website because it has only a single, well defined purpose and does not need to run complex user-facing software like a web site or email system. So the job of the attacker now becomes either to hack both systems (hard if they are deliberately set up differently), or to find a way to extract money that the supervisor won't notice. What exactly "good" vs "bad" transactions look like are merchant specific.

Whilst both credit cards and Bitcoins can experience transaction reversals, in Bitcoin the risk is entirely theoretical and has yet to be observed in the wild, whilst chargebacks are extremely common in the credit card world. Nevertheless, you should understand the risks:

• For merchants that are shipping physical goods you probably don't have to worry. Reversing a transaction gets harder and harder with time. After only one hour it becomes computationally infeasible to reverse a Bitcoin transaction. Inserting a small delay before shipping isolates you from this risk entirely.
• For automated trading platforms that may pay out some other currency in response to Bitcoin deposits, you should also delay payment for a short time until reversal becomes infeasible. Low risk deposits from trusted customers could be processed faster, as reversing a Bitcoin transaction is a non trivial problem at this time which is suited only to relatively skilled attackers who are after large sums of money.
• For merchants shipping things immediately, like digital downloads, measuring the propagation of a transaction across the network and waiting until most nodes have reported it is probably good enough. This allows you to accept the payment within seconds. Whilst there's a higher risk of transaction reversal here, the attack is still expensive and the attacker cannot choose the timing of the attack. Therefore watching out for users who receive an address and then delay the act of payment significantly is probably enough to insulate you from this attack (the Finney attack).

Backing up Bitcoin wallets is easy, as they are just files. For high volume sites with the existing software (Bitcoin 0.6), you should pre-generate a large number of keys such that a single old backup is enough to restore all your money. Future versions will derive new keys deterministically, so a single backup should be enough to ensure you can always restore your wallet after an accidental or malicious deletion.

Whilst no financial system can completely solve human gullibility, Bitcoins multi-signature keys allow you to lock up money such that multiple people have to agree in order for it to be spent. For example, the bulk of your balance could be assigned to a multi-signature key that requires you and your business partners to agree .... thus forcing a mental sanity check from multiple people, hopefully making the act of scamming harder.