Topic: Minimal quality standard I expect from an exchange (Read 3221 times)

We all need to start doing this and refuse to accept shoddy practices. Unfortunately, this would eliminate over 80% of current Bitcoin services. 

You ask them.  If they don't have a nice document or web page to point you to that details their security policy, then don't do business with them.  These details should be verified by a third party, or independently verifiable.  I am going to start doing exactly this.

You don't.  This is how regulations get started.

The real question is how do you know if an exchange is doing any of these minimal security standards?

Another way to implement this would be to have an airgapped machine with only a slow RS232 connection to the web server and port 8333 to the world (possibly also bridged by a serial connection), which imposes all of these rules, such as withdrawal requests having to be digitally signed by users or only being able to go out to the same addresses they came from.

Along a similar(ish) line, I implemented (for fun) a private-key sharing mechanism around the Armory python library... effectively you Shamir-split the private key of a user's deposit address, then only ever store one half on the server.  The other-half must be given to the user and never persisted by the exchange.

This would potentially make quite a nice protection mechanism for long-term deposits or even initial margin balances.  If the database was completely publicly exposed, you could just find the exchange's share of your key and retrieve your funds yourself.  Might be a nice stop gap until multisig comes along.

Another possibility is to require users to make their first deposits from an address they control.  Any password change, contact details change, etc. would then require the user to sign a server-generated message from that address (again Armory does this nicely).

This.  If you used JavaScript to do all the generation and password hashing then there is no way the server could even get the users password, because it is never sent.

Thank you!

it is signed with a private key derived from the password (the private key is preferably derived on the client, so that the server never sees the password. in any case, the server does not store the private key)

the server can validate because it stores the public key associated to the private key.

I look forward to what you end up producing, DAT.

Nice list.  I would add use a hardware security module to enforce
a) business rules (i.e. limits on # of tx per hour, size of tx, volume, etc)
b) delays on larger tx (i.e. tx < 100 BTC processed instantly, 100 BTC to 250 BTC delayed 1 hour, 250 BTC to 1000 BTC delayed 4 hours, 1000 BTC to hot wallet max delayed 12 hours)
c) delays on  high tx velocity (i.e. once cumulative tx in last hour exceed 3x avg hourly volume delay all tx 1 hour,  once cumulative tx in last hour exceed 5x hourly volume delay all tx 4 hours).
d) periodic status messages signing for delivery off the server (since signing key is inside HSM attacker couldn't spoof good status messages.  Attacker could block delivery of bad messages but that in itself should trigger a warning to off site monitoring).

Full disclosure I am working on a HSM for protecting Bitcoin Hot Wallets (Bitcoin Security Module).

Care to clarify on #4?

If it is just signed w/ hash of password well attacker can simply use the stored hash to sign any withdrawal as any user.
If it is signed by actual user password there is no way for the server to validate this as they don't have the actual password.

On edit:
I guess it would be possible to create a public/private key pair with the private key being based on a hash of the password (but not same hash used for login authentication) and store the public key in user's record.  When user makes a withdrawal he is prompted for password which is validated and then private key constructed to sign the withdrawal message.

Here is a set of rules designed to mitigate the effect of a server hack.

1. Cold storage. The amount of bitcoins stored on your public server (hot storage) should never exceed the capital owned by the exchange, so that if these Bitcoins are stolen the exchange can eat the loss without having to go fractional reserve.

2. To avoid breaking the above rule, Bitcoin deposits are sent directly to cold storage addresses. (for example, using deterministic generation and a master public key)

3. All transfers from cold storage to hot storage should be validated manually. For example, perform a bulk transfer every 24h, after checking that everything is normal on the server. I know that some intrusions might go unnoticed, but the most likely scenario is that an attacker would first steal the coins that are immediately available on the server, and this would not go unnoticed.

4. An attacker should not be able to disguise his theft as a set of withdrawals initiated by customers: withdrawals should be signed with a private key derived from the customer's password; during the daily manual check, compare [a hash of] the set of password-derived public keys in the server's database to [a hash of] the password-derived public keys in your database backup.

5. If the amount of withdrawal requests exceeds the amount available on the server (that is, the amount that the exchange can afford to lose), then users will have to _wait_ for the next manually validated transfer. What, waiting 24h for large withdrawals sucks? yeah, I know. That's life. As a customer, I prefer to know that my coins are safe.

6. Clone your database off server. An attacker gaining access to your server should not be able to delete your database backup.

7. Send digitally signed account statements to your customers on a regular basis. The key used to sign the statement should not reside on the public server.



Disclaimer 1:
I did not include any technical server security measures in this list (such as hashing & salting passwords, securing ports, controling access, etc)
This is because these rules are not about server security; they are about how to mitigate damage to your business should your server be compromised.

Disclaimer 2:
I have no experience running an exchange, therefore I might be wrong about what is possible and what is not. Please correct me and propose improvements.