Topic: bitfloor needs your help! - page 27. (Read 177459 times)

You could enforce some simple rules. Such as require payments into the exchange be made by an "owned" address such that withdrawls will only go back to the same address. And then check any btc withdraw against separate account balances such that people cannot withdraw more than they have on account. And then there is always that thing that Paypal and most other money handlers do - delay xfers for a few days giving time for reconciliation and verification. Given the track record of exchanges allowing instant withdraws I'd think users would be ready to put up with some delay.

But all of this is moot if you keep an unencrypted backup copy of keys anywhere even remotely possible to reach - which makes this yet another fiasco.

I've been thinking about a similar method as part of the code for an exchange I'm working on, and it's almost correct other than if somebody has access to your database and knows your rules, they can insert or alter records in the database table that controls your payment processing service.  The solution here would be to have the requests (database records) be nonced & signed.  Preferably with both a server/application private key and a per-user private key derived from the users password.

You never fully can trust it, but you can make it more difficult for an attacker by having the hot wallet independently check the incoming commands for deviations from normal patterns which could indicate the website has been compromised.

At the cost of requiring more manual human action you can add more safeguards, like requiring customers to pre-register their withdrawal addresses and transferring a list of valid addresses via sneakernet to the hot wallet every 8 hours. Now an attacker can't break into the website and send the hot wallet a command to withdraw all the bitcoins to some arbitrary address because that address won't be on the authorized list.

Well no security system is absolutely foolproof.  Even a 100% cold wallet can be compromised by physically attacking the cold wallet and/or operator.  The idea is to make the attack harder.

The hot wallet can validate commands internally.  For example it could limit the tx based on:
a) limit per hour
b) max limit until supervisor reset
c) limit per tx/address
d) limited to only preset withdraw addresses (adhoc address may be allowed but at lower limit)

If the attacker can't steal the keys directly, and must send commands to the hot wallet indirectly the attack becomes more difficult and the amount limited.  It is possible the attacker doesn't know that a withdraw request of 6,000 BTC will trigger a lockout and in doing so prevents him from stealing anything.   Combine that with sending all incoming funds to a cold wallet and only keeping say 10% of total funds in hot wallet and the potential theft becomes even more limited.

Even simply limiting the size of the hot wallet to say 10% of total funds and doing nothing else would have limited the attack to ~$20,000.  That is a bad breech but far easier to overcome than a complete loss of funds.

That's correct. There are serious risks if you don't have incoming bitcoins go directly to the cold wallet.

For example, recently an exchange was hacked with a bogus LR transfer. The hackers bought up Bitcoins and pushed the price up to some absurd amount. This encouraged people to deposit more Bitcoins in their accounts to sell them at the bogus rate. If deposits had gone to the hot wallet, these deposits could have been stolen as well.

Right, that's why you don't keep that much money in the hot wallet. A starting point is your average one-day volume.

You can't. That's the point of the hot wallet. It holds the coins you can afford to lose if you're hacked.

You can't, that's why you don't keep a lot of money in the hot wallet.

To be clear, you do make the hot wallet as secure as you can. But the risks you mention above are fundamental and they are the reason having a cold wallet is essential. If an account is holding more than about $100,000, the keys to that account should never appear on any one machine that provides remote access from the Internet.

Thanks for the replies.

I guess most newly incoming bitcoins can go straight to the cold wallet and have the exchange run on a manually updated hot wallet.

It's more the hot wallet I'm trying to understand. It is needed for the exchange to instantly process transactions directed by customers. So there'll always be a kind of command path going from website to wallet, no matter how far away you hide the hot wallet, and we'll have to trust that path we setup ourselves. A good hacker will find that path and command the bitcoind. So there's actually no need to trust our path if we can't trust our website.

Now, of course you can have the hot wallet pull for commands and transactions, but then.. how do you trust the content of those commands and transactions? Because, basically, that is that same public website with input from customers.

If we can't trust the website giving commands into the hot wallet, [edited:]how can we trust that same website to collect and offer the hot wallet valid and intended commands to pull?

IMO the best solution is this: https://bitcointalksearch.org/topic/ann-bitcoinarmory-daemon-armory-on-web-servers-92496 (Armory on web servers)

Plus an offline wallet to store the bulk of the reserves, not in any actual running computer connected to anything. http://bitcoinarmory.com/index.php/using-offline-wallets-in-armory

If etothepi could commit to Bitfloor I'd be all over the IPO with a 100K+ valuation.

Sheesh ... 25K unencrypted keys lying around at an exchange ... really??

I'm sure they were doing all the right AML/KYC fiat protection racket crap though ... it does make one wonder if any of these exchanges have actually been set-up intentionally to fail?

Maybe time for another Goxing?

Yep, this is a no brainer.

I'm no expert on security matters and am not familiar with what the current best practices are in such a matter, so there are probably better solutions than the one I'm about to explain.  Regardless, as a system architect, it only took me a few seconds to come up with one possible solution to your question:

While nothing should be allowed to connect in to the wallet box, processes on the wallet box can still reach out to other boxes.

A separate daemon can be written to run on the wallet box and reach out regularly (every second?) to a database held on some other box.  Entries in this database can indicate actions that should be taken on the hot wallet (procedure numbers to indicate which function to run, additional columns or tables to hold parameters).  The daemon can be written to validate the database entries against a set of sanity checks (size, frequency, destination, etc). It can then trigger an alert (pager, txt msg, phone call) to system administrators and refuse to process the request from the database when any transaction, or set of transactions, exceeds any sanity check.  System administrators can then determine if the attempted interaction with the hot wallet is legitimate and handle the situation as needed. If the private keys for the hot wallet are known to be kept offline in cold storage, the daemon can even shut down bitcoind and delete the local copy of wallet.dat when it detects any obvious sign of intrusion.

Polling another box? Connections allowed only from select IPs?

The secluded server will have a payment processor that will access the production database from behind a firewall, verify transactions for fraud and send the payments out.

IMO, the best solution is to walk a request to the box. You can also have the box connect out to a web server that provides it with transfer requests that then just have to be manually approved at the box. The most common transaction will be to move coins to the cold wallet, so all you need is an amount.

How do you solve getting to the secluded bitcoind to command it to sent bitcoins out?

Bitfloor Hacked, $250,000 Missing (bitcoinmagazine.net)
http://news.ycombinator.com/item?id=4477376

http://www.reddit.com/r/Bitcoin/comments/zchfn/bitfloor_hacked/

http://arstechnica.com/tech-policy/2012/09/hacker-steals-250k-in-bitcoins-from-online-exchange-bitfloor/

Bitcoins sold, let's wait for a FUD storm! I expect the price to hit <$8 in next few days.

The story got picked up quickly by Arstechnica, C-Net et all.

Bit Flaw 

Perhaps one of the large creditors that had a large amount of USD or BTC on BitFloor has some balls and wants to double down. Where's Matthew when you need him

I don't see an investor buying a business with such a low entry barrier, a quarter million dollar debt, and (AFAIK) no valuable partnerships or financial licenses.