Proposal for Security Standards for Bitcoin Exchanges

[fellowtraveler]

Someday, enough money will be stolen that the Bitcoin community will consider using public key cryptography that was invented back in the 70s.


Proposal for Security Standards for Bitcoin Exchanges (and any other "centralized" storage of people's money)

Everyone: please add your own security proposals to this thread.  :-)

-- NO passwords should be stored on server OR client side.

-- No client-side passwords should be used on the server side at all (hashed or not.)

-- ALL transaction requests must be digitally signed on the client side.

-- All transaction receipts must be server-signed (and must contain a copy of the original client-signed request.) This prevents the server from forging any of your transactions.

-- Receipt should prove the current balance, and the newest receipt is always the winner in any dispute. (Meaning the receipt IS the account.) This prevents the server from changing your balance without permission.

-- Receipt should also prove which instruments are valid and which transactions have cleared. (Meaning the receipt IS the transaction history.) This prevents any instruments you haven't authorized from impacting your account.

-- All recurring transactions (such as trades processing over time from a specific market offer) should result in a server-signed receipt in the user's inbox.

-- All market trades should contain a copy of the user's original signed offer, as well as details on how many trades have processed from the offer.

-- All server requests must contain a request number that increments with each message. This prevents attackers from intercepting messages and sending them again.

-- All server requests must contain the server ID that the message is intended for. This prevents attackers from intercepting messages and sending them to other servers.

-- All transactions must contain a transaction number that was previously issued (and signed for). These numbers must be listed on every receipt until signed as closed. (Server can prove entire transaction history without having to store it.)

-- All transactions must contain a signed balance agreement. All incoming receipts must be verifiable against the last signed balance agreement.

-- All source code must be publicly available for audit.

-- All source code must be subjected to an automated code scanner. (Static AND dynamic analysis.)

-- All Bitcoins must be bailed into a system such that individual servers cannot steal bitcoins from their own users, or be hacked and have hackers steal bitcoins from their users. (This is technically possible in Bitcoin...)

-- All currencies issued on the server, including Bitcoins, must have reserves that are publicly auditable.

Also preferable:
-- Users should sign all transactions on a crypto-card.
-- An additional authentication layer should be provided via crypto-tokens with passwords that change every 90 seconds.

These are the standards I demand for anyone who is going to hold my money.

How about you?

[1713942152]

1713942152

[da2ce7]

Sounds Like an exchange that I'd like to use. 

[koin]

These are the standards I demand for anyone who is going to hold my money.

since none are even close to following these, you probably don't have anyone holding your money then?

[Vladimir]

ISO 27001

[DeathAndTaxes]

When designing a standard the repetitive use of the words ALL and MUST are well, repetitive, especially when used in every bullet point. If you are designing a standard it is implicit that ALL x MUST do y if you just say x do y.   As an example Bitcoin standard doesn't say things like ALL transactions MUST be signed by the private key.  It is understood when someone says transactions are signed by the private key of the input that it i applies to ALL txs and the signing MUST occur each time (not sometimes and not optionally).

User authentication is handled by Public Key Cryptography.  No passwords are used by the exchange.

Transactions are digitally signed by the client.
Transactions will imlement an incrementing nonce to prevent a replay attack.
Transactions will implement a unique server id (server public key ? ) to prevent redirection attack.

Server will return a transaction receipt for each transaction made by the client.

Transaction receipts contain the original client signed transaction and are digitally signed by the server.
Transaction receipts should contain account current balance(s).
Transaction receipts will contain a transaction ID as well as the prior transaction's transaction ID.

[davout]

Someday, enough money will be stolen that the Bitcoin community will consider using public key cryptography that was invented back in the 70s.

Proposal for Security Standards for Bitcoin Exchanges (and any other "centralized" storage of people's money)

Everyone: please add your own security proposals to this thread.  :-)

[...]

These are the standards I demand for anyone who is going to hold my money.

How about you?

Good job describing OT (which is a very cool project). But by no means a one-size-fits all solution to all security issues.

[davout]

Sounds Like an exchange that I'd like to use. 

I bet you would

[glub0x]

Other things that i do like
--> the no link in e mail policy (phishing)
--> the fake javascript on screen keyboard used in baking online systems . (keylogers)
--> a "evident" login history (always visible, with the login ip, time, AND flags for suspect logins)

[fellowtraveler]

When designing a standard the repetitive use of the words ALL and MUST are well, repetitive, especially when used in every bullet point. If you are designing a standard it is implicit that ALL x MUST do y if you just say x do y.   As an example Bitcoin standard doesn't say things like ALL transactions MUST be signed by the private key.  It is understood when someone says transactions are signed by the private key of the input that it i applies to ALL txs and the signing MUST occur each time (not sometimes and not optionally).

User authentication is handled by Public Key Cryptography.  No passwords are used by the exchange.

Transactions are digitally signed by the client.
Transactions will imlement an incrementing nonce to prevent a replay attack.
Transactions will implement a unique server id (server public key ? ) to prevent redirection attack.

Server will return a transaction receipt for each transaction made by the client.

Transaction receipts contain the original client signed transaction and are digitally signed by the server.
Transaction receipts should contain account current balance(s).
Transaction receipts will contain a transaction ID as well as the prior transaction's transaction ID.

Great feedback! Thanks.

[fellowtraveler]

Someday, enough money will be stolen that the Bitcoin community will consider using public key cryptography that was invented back in the 70s.

Proposal for Security Standards for Bitcoin Exchanges (and any other "centralized" storage of people's money)

Everyone: please add your own security proposals to this thread.  :-)

[...]

These are the standards I demand for anyone who is going to hold my money.

How about you?

Good job describing OT (which is a very cool project). But by no means a one-size-fits all solution to all security issues.

I'm not trying to just describe OT as a "one size fits all" solution.

Rather, I'm trying to get everyone to add their own security proposals to this thread.

First, so I can steal all their ideas.

Second, because clearly, people in this community are not talking about security mechanisms enough, and are not implementing security mechanisms enough -- they are not thinking about security mechanisms enough.

And as I said a long time ago, people in this community are going to continue to "get screwed" until they do.

(At this point, I can basically set my watch by the regularity of high-profile thefts that occur in this community.)

[DarkEmi]

- Have all owners and employees declare all btc accounts they own and use and all their accounts at every exchange (not publicly), if they ever are caught using an undeclared accounts that might mean something is fishy

=> This is required in the banking industrie

- Have operators & CTO not brag about their hacking skills on chats and posting youtubes video in place of official statements

OP : your proposals are good

[davout]

First, so I can steal all their ideas.

Second, because clearly, people in this community are not talking about security mechanisms enough, and are not implementing security mechanisms enough -- they are not thinking about security mechanisms enough.

I see, I'd add : "use the minimum necessary privileges for API access tokens" but it seems like a no-brainer.
Also you're forgetting the whole human side of the equation, in the last high-profile thefts the lack of access segregation + lack of auditing probably allowed the weakest link to easily break.
So I'd also add : "know who has access to what, exactly"

[Stephen Gornick]

(At this point, I can basically set my watch by the regularity of high-profile thefts that occur in this community.)

Yup, BitFloor's was right on time!