Bitcoin Forum
December 07, 2016, 12:58:30 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Minimal quality standard I expect from an exchange  (Read 2777 times)
ThomasV
Legendary
*
Offline Offline

Activity: 1722



View Profile WWW
May 27, 2012, 02:02:34 PM
 #1

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.

Electrum: the convenience of a web wallet, without the risks
1481115510
Hero Member
*
Offline Offline

Posts: 1481115510

View Profile Personal Message (Offline)

Ignore
1481115510
Reply with quote  #2

1481115510
Report to moderator
1481115510
Hero Member
*
Offline Offline

Posts: 1481115510

View Profile Personal Message (Offline)

Ignore
1481115510
Reply with quote  #2

1481115510
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
May 27, 2012, 02:37:50 PM
 #2

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.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
May 27, 2012, 02:42:28 PM
 #3

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).
proudhon
Legendary
*
Offline Offline

Activity: 1148



View Profile
May 27, 2012, 02:43:31 PM
 #4

Nice list.  I would add use a hardware security module to enforce
a) business rules (limits on # of tx per hour, size of tx, volume, etc)
b) delay 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) delay high velocity tx (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) sign periodic status messages for delivery off the server (attack could block delivery but that in itself should trigger a warning to off site monitoring).

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


I look forward to what you end up producing, DAT.
ThomasV
Legendary
*
Offline Offline

Activity: 1722



View Profile WWW
May 27, 2012, 02:46:00 PM
 #5

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.

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.



Electrum: the convenience of a web wallet, without the risks
Littleshop
Legendary
*
Offline Offline

Activity: 1316



View Profile WWW
May 27, 2012, 03:28:44 PM
 #6


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


Thank you!

ErebusBat
Hero Member
*****
Offline Offline

Activity: 560

I am the one who knocks


View Profile
September 04, 2012, 07:40:21 PM
 #7

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.

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.
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.

░▒▓█ Coinroll.it - 1% House Edge Dice Game █▓▒░ • Coinroll Thread • *FREE* 100 BTC Raffle

Signup for CEX.io BitFury exchange and get GHS Instantly!  Don't wait for shipping, mine NOW!
wheeler
Jr. Member
*
Offline Offline

Activity: 30


IRC: ChoiceMarket


View Profile
September 04, 2012, 10:02:14 PM
 #8


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.


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).
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
September 04, 2012, 10:08:57 PM
 #9

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.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
stochastic
Hero Member
*****
Offline Offline

Activity: 532


View Profile
September 05, 2012, 12:08:09 AM
 #10

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

Introducing constraints to the economy only serves to limit what can be economical.
ErebusBat
Hero Member
*****
Offline Offline

Activity: 560

I am the one who knocks


View Profile
September 05, 2012, 02:37:57 AM
 #11

The real question is how do you know if an exchange is doing any of these minimal security standards?
You don't.  This is how regulations get started.

░▒▓█ Coinroll.it - 1% House Edge Dice Game █▓▒░ • Coinroll Thread • *FREE* 100 BTC Raffle

Signup for CEX.io BitFury exchange and get GHS Instantly!  Don't wait for shipping, mine NOW!
SkRRJyTC
Legendary
*
Offline Offline

Activity: 966


View Profile
September 05, 2012, 03:12:47 AM
 #12

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

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.
IveBeenBit
Sr. Member
****
Offline Offline

Activity: 448



View Profile
September 05, 2012, 03:20:55 AM
 #13

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.

We all need to start doing this and refuse to accept shoddy practices. Unfortunately, this would eliminate over 80% of current Bitcoin services.  Undecided
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!