Security Guidelines for BitCoin Exchange Markets

[smartcardguy]

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?

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.

[1713877760]

1713877760

[1713877760]

1713877760

[1713877760]

1713877760

[1713877760]

1713877760

[1713877760]

1713877760

[MBH]

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?

[ascent]

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.

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]

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?

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

[MBH]

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?