Bitcoin Forum

As bitcoin usage is increasing and exchanges are booming, it's necessary for users to feel secure when investing money, thus the need for security guidelines for these exchanges to follow in order to have a secure infrastructure.

This is a draft, suggest by user ascent, and below are our expectations of how exchanges should be secured (infrastructure wise, and maybe procedures too). Make your suggestions and explain them. I'll edit the post and update it.

I hope the mods pin this and eventually add it to the official bitcoin wiki so that it's followed by exchange markets.

Data Security:

• Passwords must be hashed using SHA-512 or BlowFish derived ciphers that are slow in computation, slowing down brute force attacks.
• Proper hash salting must be applied. Details: http://forum.bitcoin.org/index.php?topic=20720.msg260974#msg260974
• Separate user login data from user transaction data. Auditors need access to the latter only.

Trading Procedures:

• The exchange must state what kind of circuit breaker protocols are used in place. Explanation: http://forum.bitcoin.org/index.php?topic=20720.msg259385#msg259385
• The exchange must state its operating hours and holidays.
• The exchange must state what security measures are in place should it operate 24/7 or at certain hours and when security updates would be rolled out.

Profile Information:

• Require putting the current password when changing any profile settings.
• Allow for use of an alternate email address (Like GMail).
• Allow changing the alternate address only after an email has been sent to it, not the main one, in case the account got compromised.

Login:

• Use CAPCTHA or similar methods to prevent automated brute-force attacks on logins.
• Provide an option to lock an account for a certain time after a certain number of failed attempts to login.
• A welcome screen should be presented to show an image and a text chosen by the user when the account was created, to make sure the user logged into the right site & not a hijacked/spoofed one.

APIs:

• Streaming updates to the order book (market depth, profile, etc.) should include order IDs such that the client can accurately update its own version of the order book.

Networking:

• Database & web servers should reside behind a firewall and only reachable via proxies.
• The database should be a separate machine from the web server and only reachable from the webserver, or specific machines in the network.
• Exchanges must declare its networking design to show the location of servers, firewalls and other equipment.
• SSL/TLS must be used at all times for all operations.
• Auto logout must be used, but the timeout period is configurable by the user.
• Use security tokens in forms to prevent Cross-site Request Forgery (CSRF)
• Sanitize all data coming from users.
• View a list of last used IP addresses logged into the account (Like GMail).
• Use of Intrusion prevention systems and daily review of attacks or patterns.

Corporate Protocols:

• Define the number of workforce either in strict terms (10, for example) or approximate (5-8 people as web devs, for example).
• Backup procedures: How often are backups taken. Where are backups kept. How often are test-restores performed.
• Access to any of the systems or databases must be from a clean machine from within the corporate to avoid external attacks (virus infections).
• The exchange should promote security best practices to clients.

Currency Calculations:

• Currency values and amounts should be computed and stored using integer arithmetic only, as opposed to floating point which can lead to round off errors. Explanation: http://forum.bitcoin.org/index.php?topic=20720.msg260369#msg260369

Exchanges must post the exact parameters in use for any circuit breakers they choose to have in place. It is not being suggested that exchanges have circuit breakers, only that they most be upfront and specific about what they are.

Could you define what you mean with "circuit breakers" ?

A circuit breaker would be a rule in place that halts trading for some specified period of time (maybe until the end of the trading session for the day) if a move of a certain magnitude occurs within a certain amount of time.

I have seen various suggestions in these forums, and to be honest, they all specify a move that is way too small as the trigger, i.e. 10 percent. I'm not necessarily advocating the use of circuit breakers, only saying that an exchange needs to disclose what circuit breakers are in place.

In this volatile and immature market, if they are put in place, a pretty large move should be required to trigger one, something like 30 percent in three minutes, or 75 percent in any 4 hour period. I just think it's unrealistic to do anything more constraining in this emerging market.

But again, I'm not stating that exchanges should have circuit breakers, only saying that they need to disclose up front what circuit breakers are in place.

Updated the list.

They must state explicitly the hours they are open for trading during the day, and what days they are closed for trading.

On a slightly different note, they should state what measures they have in place to allow for security updates if they choose to be open 24/7.

If one is to use a password based authentication system which has to use is less important than how you use it, specifically what scheme you apply to salting; While larger hashes even with proper hashing increase the amount of memory needed for pre-computed tables it doesn't eliminate the threat, proper salting can.

I would add that the most important elements a web authentication infrastructure offers as a mitigation's are related to how account lockout and recovery works.

Additionally integration of multi-factor authentication technique's, for example "enrolling" a machine as a legitimate console in which trading can occur from by setting a AES key into the cookie post "enrollment" that has to be present for authentication into the account without additional account proofs also help a lot and do not (if done correctly) make the usability of the system poor.

Generally I encorage customers o adopt authentication frameworks (ala OpenID, Facebook, etc) or federate, however I dont think this is appropriate for exchanges; in that the security needs of these systems are different and you expose yourself to their risks (to some degree) by doing this.

Transaction thresholds that escelate based on reputatation (transaction history, norms, etc) are also very valuable, though I can appriciate that there would resistance to this but it can be one of the most effective mitigations.

CAPCTHA offers very limited value, account lockout is more approprite.

smartcardguy,
Please don't quote the whole thing. Just add what you want directly.

Was a editorial mistake, fixed.

If the exchange is going to offer an API which allows streaming updates to the order book (market depth, profile, etc.), then those streaming updates should include order IDs such that the client can accurately update its own version of the order book.

Databases should reside behind a firewall accessible only by a proxy server. The exchange should disclose whether their database(s) does or does not reside behind a firewall and limits what can access it directly.

smartcardguy,

Account lockout is very frowned upon since it can be used for denial of service. I used to do it to certain abusers on Hotmail before when it employed that method.

Enrolling/trusting certain machines can be useful but also dangerous because if your session/cookie is hijacked, then no password is required and you're immediately impersonated. Personally, I only login from my own devices (laptop or phone) and not anyone else's, but I still wouldn't want to allow for the chance of having a cookie stolen allowing access to my account and enabling other systems as authorized systems.

Regarding passwords & hash salting, BlowFish has a very small footprint on memory (4kB) but dictionary attacks are extremely slow because that's how the crypto was designed (details on Wikipedia). I have a friend who was brute forcing passwords on graphics cards; he was doing 4000 million pwds/sec of MD5, but only 200 pwds/sec on blowfish. See the difference?

I would leave that at the discretion of exchange operators. I'm sure they wouldn't want to disclose all types of security and their rollout times.

This is a great idea. I think we should develop guidelines for ALL bitcoin businesses... more on this later. :)

We're not asking them to disclose what security breaches are there. Only when they plan to roll such updates, how often, ...etc.

EmilyClark,
Whatever is mentioned here can be used by *any* online service, as it is not specific to bitcoins.

I believe that they must also have the server power, having at least multiple servers, DNS's, firewalls, DDOS protection etc. A real exchange unlike the current ones should have hired employees that work full time instead of one person doing everything from security to operating the website...

I think the intent here is that an exchange has two ways to operate and should disclose their intent either way:

1) They are periodically closed (and state exactly when they are closed), to allow for maintenance and security updates.
2) They are open 24/7, and thus, owe the community an explanation as to their ability to provide security updates if they do operate 24/7.

Regarding networking, I believe the proper model is to have the web server a separate machine from the database, and only allow connection to the database server (the whole machine) from the web server, as opposed to the Internet at large.

All calculations with currency values and amounts should be computed and stored using integer arithmetic only, as opposed to floating point, which can lead to round off errors.

BitCoin is divisible to the 8th decimal point and could be expanded in the future. Integer-only transactions won't work.

That's true, but it depends on the account lockout scheme used and the thresholds applied; those issues can be mitigated to some extent and the technique can even be applied proportionally to the risk, I presume someone would rather have an account with half a million USD of BTC in it locked out on 10 failed password attempts than have that money lost.

As for machine authentication as a factor, when this is done it is just one factor (password + machine key) it does not have the properties of a session cookie which is what you described; additionally when implemented its done with cookies that only go over TLS to that site so while cookies can always be stolen with access to the local cookie store or with use of another attack vector this approach is very effective at mitigating account takeover issues with minimal use experience impact.

I am familiar with Blowfish's security and performance properties :)

My point was that length a hash algorithm outputs is a consideration in addition to its computational performance characteristics, specifically it has bearing on the time-memory trade-off problem; see http://en.wikipedia.org/wiki/Rainbow_tables.

No system that needs to authenticate users should store a flat hash, they should all salt.

smartcardguy,

Should the salting scheme be disclosed to the public?
Disclosing it would certainly provide the attacker with easier cracking, but using salting would generally mean rainbow tables are pointless, no?

Actually, that is precisely why floating point calculations don't work. Floating point calculations introduce round off error and are unable to store certain numbers. Integer calculations can handle any decimal point and can store any number, given enough bits.

Integer arithmetic with numbers that have decimal places are handled by performing all internal calculations with numbers multiplied by, say 100 million. No loss of precision ever occurs, unlike with floating point numbers. To print the number to the user simply requires inserting a dot at the appropriate place.

The scheme being public isnt a problem, there is little security in obscurity. IMHO a modern system that relies on passwords should use at least 128bit random salt per password, that salt can simply be stored in the clear with the salted hash as this simply increases the size of the precomputed hash table necessary to look up the clear text password and doesnt require any special protections.

Other things that should be considered in such systems is segmenting out the privliges necessary to perform the authentication from those necessary to perform transactions; this means you can have role seperation and you can let auditors look at your financial data without having to wory about them having access to your account table :)

21st-century

• An on screen key-board should be available to enter passwords should the user wish to avoid potential key-loggers on their machine. The location of the keys should be randomly generated to make recording mouse movement impossible leaving the only option of recording the screen.

If you suspect that your machine has a keylogger, you shouldn't be using it in the first place.

• An expiration for cookies should be user specifiable.
• Accounts should automatically log out after x minutes.

What's the difference? If you're logged out, your session/cookie is no longer valid.

• Complexity of passwords should be such that brute forcing the login form or the hash is computationally impossible.

While you could enforce minimum password length, enforcing complexity results in Sticky-Note Security: Users won't remember the passwords & instead write them down & paste them on their monitors or write them in their phones.

• Security alerts emailed to users after x amount of invalid attempts.

Why annoy the user with failed attempts? The attacker can be block listed for 15 minutes (based on IP/Browser/Cookie).

• User definable limits on withdrawal.

What difference does it make? If an attacker gained access to the account, s/he could change that limit.

• Only services on the exchange that need to be accessible should be.
• Vigorous logging of activity should occur.
• The exchange should audit the clients for the potential of them being exploited by a side-channel attack.

Elaborate please.

• Exchange internal and external network should be audited and secure.

By whom?