Topic: Security Guidelines for BitCoin Exchange Markets (Read 2322 times)

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?

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

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.

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?

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.

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

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.

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.

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.

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

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

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

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

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.

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?

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.

Was a editorial mistake, fixed.

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

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.

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.